Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stdatomic.h raises missing types for AstNode { ... __ATOMIC_SEQ_CST } #293

Open
chrysn opened this issue Sep 3, 2020 · 3 comments · May be fixed by #302
Open

stdatomic.h raises missing types for AstNode { ... __ATOMIC_SEQ_CST } #293

chrysn opened this issue Sep 3, 2020 · 3 comments · May be fixed by #302

Comments

@chrysn
Copy link
Contributor

chrysn commented Sep 3, 2020

Whenever c2rust encounters stdatomic.h in my setup, it fails irrecoverably with messages like this:

  warning: Missing type 94827692380208 for node: AstNode { tag: TagTypedefDecl, children: [], loc: SrcSpan { fileid: 81, begin_line: 97, begin_column: 1, end_line: 97, end_column: 37 }, type_id: Some(94827692380208), rvalue: LValue, macro_expansions: [], macro_expansion_text: Some("__ATOMIC_SEQ_CST"), extras: [Text("atomic_uint_least32_t"), Bool(false)] }
  Exported Clang AST was invalid. Check warnings above for unimplemented features.
  --> /usr/lib/llvm-10/lib/clang/10.0.1/include/stdatomic.h:97:1
   [-Wclang-ast]
  thread 'main' panicked at 'Could not find CTypeId(4932) in TypedAstContext', c2rust-transpile/src/c_ast/mod.rs:816:21

(The block from warning: to [-Wclang-ast] is repeated dozens of times; all earlier warnings are unrelated "macro redefined" ones).

As support for LLVM 10.0.1 is rather recent, it might be related to that. I'm using Rust nightly-2020-08-29, and LLVM 10.0.1 as in the above error messages..

Full compile_commands.json in case it's relevant ``` [ { "arguments": [ "any-cc", "-DTHREAD_STACKSIZE_MAIN=(THREAD_STACKSIZE_DEFAULT + 5000)", "-DDEVELHELP", "-Wall", "-Wextra", "-pedantic", "-g3", "-std=gnu11", "-m32", "-fstack-protector-all", "-ffunction-sections", "-fdata-sections", "-DDEBUG_ASSERT_VERBOSE", "-DRIOT_APPLICATION=shell_threads", "-DBOARD_NATIVE=native", "-DRIOT_BOARD=BOARD_NATIVE", "-DCPU_NATIVE=native", "-DRIOT_CPU=CPU_NATIVE", "-DMCU_NATIVE=native", "-DRIOT_MCU=MCU_NATIVE", "-fno-common", "-Wall", "-Wextra", "-Wmissing-include-dirs", "-fdiagnostics-color", "-Wstrict-prototypes", "-Wold-style-definition", "-gz", "-Wformat=2", "-include", "/home/chrysn/git/crates/riot-examples/shell_threads/bin/native/riotbuild/riotbuild.h", "-DRIOT_VERSION=2020.10-devel-1190-ga75d3", "-DMODULE_AUTO_INIT", "-DMODULE_AUTO_INIT_XTIMER", "-DMODULE_BOARD", "-DMODULE_CORE", "-DMODULE_CORE_IDLE_THREAD", "-DMODULE_CORE_INIT", "-DMODULE_CORE_MSG", "-DMODULE_CORE_PANIC", "-DMODULE_CPU", "-DMODULE_DIV", "-DMODULE_NATIVE_DRIVERS", "-DMODULE_NETDEV_REGISTER", "-DMODULE_PERIPH", "-DMODULE_PERIPH_COMMON", "-DMODULE_PERIPH_GPIO", "-DMODULE_PERIPH_GPIO_LINUX", "-DMODULE_PERIPH_INIT", "-DMODULE_PERIPH_INIT_GPIO", "-DMODULE_PERIPH_INIT_GPIO_LINUX", "-DMODULE_PERIPH_INIT_PM", "-DMODULE_PERIPH_INIT_TIMER", "-DMODULE_PERIPH_INIT_UART", "-DMODULE_PERIPH_PM", "-DMODULE_PERIPH_TIMER", "-DMODULE_PERIPH_UART", "-DMODULE_PS", "-DMODULE_SHELL", "-DMODULE_SHELL_COMMANDS", "-DMODULE_STDIN", "-DMODULE_STDIO_NATIVE", "-DMODULE_SYS", "-DMODULE_XTIMER", "-I/home/chrysn/git/crates/riot-examples/RIOT/core/include", "-I/home/chrysn/git/crates/riot-examples/RIOT/drivers/include", "-I/home/chrysn/git/crates/riot-examples/RIOT/sys/include", "-I/home/chrysn/git/crates/riot-examples/RIOT/boards/native/include", "-DNATIVE_INCLUDES", "-I/home/chrysn/git/crates/riot-examples/RIOT/boards/native/include/", "-I/home/chrysn/git/crates/riot-examples/RIOT/core/include/", "-I/home/chrysn/git/crates/riot-examples/RIOT/drivers/include/", "-I/home/chrysn/git/crates/riot-examples/RIOT/cpu/native/include", "-I/home/chrysn/git/crates/riot-examples/RIOT/sys/include", "-I/home/chrysn/git/crates/riot-examples/RIOT/cpu/native/include", "riot-c2rust.h" ], "directory": "/home/chrysn/git/crates/riot-examples/shell_threads/target/i686-unknown-linux-gnu/debug/build/riot-sys-4eef4926f1212a50/out", "file": "riot-c2rust.h" } ] ```

I got stuck trying to drill down on this; from the lookup I'd have expected something atomic-ish to be registered earlier in TypedAstContext.c_types, but all those are populated using ConversionContext::add_type through ConversionContext::visit_node, and if anything unhandled had shown up there it should have fallen into the large match's _ => panic branch, which obviously didn't happen. (That's from a very high-altitude survey, though; there's countless details I can have missed here.)

@thedataking
Copy link
Contributor

The C11 _Atomic quantifier is not supported so that might be it. Of course, we should emit a proper error message. Can you point me to the code you are testing on or share a minimal test case that reproduces the issue?

(Also, please note that you must use the rust nightly version in rust-toolchain, otherwise c2rust will not build.)

@chrysn
Copy link
Contributor Author

chrysn commented Sep 4, 2020

_Atomic quantifier is not supported

That does explain things; it would be nice though if it'd be possible to get transpilation at least for functions that don't (maybe even transitively) depend on these types, even when a header is included that pulls in stdatomic. (In the RIOT-OS codebase I'm working with, that's maybe 20% of the headers).

Minimal example

As for minimal example, this is how I've managed to produce errors like the above:

compile_commands.json:

[{
        "arguments": ["any-cc", "test.c"],
        "file": "test.c",
        "directory": "/tmp/minimal-transpile-example/"
}]

test.c:

#include <stdatomic.h>

Alternatively, indeed, the file can also be the first offending line from stdatomic, which is:

typedef _Atomic(char)               atomic_char;

Command execution:

$ c2rust transpile compile_commands.json
Transpiling test.c
warning: Missing type 94736737888928 for node: AstNode { tag: TagTypedefDecl, children: [], loc: SrcSpan { fileid: 7, begin_line: 88, begin_column: 1, end_line: 88, end_column: 37 }, type_id: Some(94736737888928), rvalue: LValue, macro_expansions: [], macro_expansion_text: Some("__ATOMIC_SEQ_CST"), extras: [Text("atomic_ullong"), Bool(false)] }
Exported Clang AST was invalid. Check warnings above for unimplemented features.
--> /usr/lib/llvm-10/lib/clang/10.0.1/include/stdatomic.h:88:1
 [-Wclang-ast]
[... repeated similar messages elided ...]
warning: Missing type 93859071368176 for node: AstNode { tag: TagTypedefDecl, children: [], loc: SrcSpan { fileid: 7, begin_line: 80, begin_column: 1, end_line: 80, end_column: 37 }, type_id: Some(93859071368176), rvalue: LValue, macro_expansions: [], macro_expansion_text: Some("__ATOMIC_SEQ_CST"), extras: [Text("atomic_uchar"), Bool(false)] }
Exported Clang AST was invalid. Check warnings above for unimplemented features.
--> /usr/lib/llvm-10/lib/clang/10.0.1/include/stdatomic.h:80:1
 [-Wclang-ast]
thread 'main' panicked at 'Could not find CTypeId(177) in TypedAstContext', c2rust-transpile/src/c_ast/mod.rs:810:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Workaround

This exercise has led me to see that adding a #define _Atomic(x) x to the headers does work around the immediate problem -- with the downside that it will silently produce erroneous (non-atomic) code where atomics are actually used.

@chrysn
Copy link
Contributor Author

chrysn commented Sep 18, 2020

On the tour through the code for what'd be needed to actually implement this, I found that this is a two-staged error: If the test file just contains variables or fields like _Atomic(int) x = 1;, "all is fine" in that it hits an error like test.c:4:15: error: c2rust: C11 Atomics are not supported. Aborting.. Only when a typedef (like the one in stdatomic) is encountered where an _Atomic(x) "expression" is used in the typedef, then the shown errors crop up.

I'll treat this issue as revolving around the steps of how to get into a regular printC11AtomicError error case from the typedefs, and then have a look at what it'd take to actually make atomics usable.

chrysn added a commit to chrysn-pull-requests/c2rust that referenced this issue Sep 18, 2020
This does not help towards the support of C11 atomics, but ensures that
the existing error messages about the trouble with them get shown:

* In VisitQualType at latest, where the source location information is
  already gone so it's not that helpful (but at least it should catch a
  wide range of sources where those types could come from)

* In VisitTypedefNameDecl, where the `typedef _Atomic(...) atomic_...;`
  declarations of clang's stdatomic.h run through. It's but one of many
  possible callers, but it's the one where one more check can make the
  difference between a usable and a cryptic error for many cases.

Closes: immunant#293
@chrysn chrysn linked a pull request Sep 18, 2020 that will close this issue
chrysn added a commit to chrysn-pull-requests/c2rust that referenced this issue Jan 6, 2021
This does not help towards the support of C11 atomics, but ensures that
the existing error messages about the trouble with them get shown:

* In VisitQualType at latest, where the source location information is
  already gone so it's not that helpful (but at least it should catch a
  wide range of sources where those types could come from)

* In VisitTypedefNameDecl, where the `typedef _Atomic(...) atomic_...;`
  declarations of clang's stdatomic.h run through. It's but one of many
  possible callers, but it's the one where one more check can make the
  difference between a usable and a cryptic error for many cases.

Closes: immunant#293
chrysn added a commit to RIOT-OS/rust-riot-sys that referenced this issue May 31, 2022
chrysn added a commit to chrysn-pull-requests/c2rust that referenced this issue Jun 8, 2022
This does not help towards the support of C11 atomics, but ensures that
the existing error messages about the trouble with them get shown:

* In VisitQualType at latest, where the source location information is
  already gone so it's not that helpful (but at least it should catch a
  wide range of sources where those types could come from)

* In VisitTypedefNameDecl, where the `typedef _Atomic(...) atomic_...;`
  declarations of clang's stdatomic.h run through. It's but one of many
  possible callers, but it's the one where one more check can make the
  difference between a usable and a cryptic error for many cases.

Closes: immunant#293
@kkysen kkysen changed the title stdatomic.h raises missing types for AstNode { ... __ATOMIC_SEQ_CST } stdatomic.h raises missing types for AstNode { ... __ATOMIC_SEQ_CST } Jun 29, 2022
kkysen pushed a commit that referenced this issue Jun 29, 2022
This does not help towards the support of C11 atomics, but ensures that
the existing error messages about the trouble with them get shown:

* In VisitQualType at latest, where the source location information is
  already gone so it's not that helpful (but at least it should catch a
  wide range of sources where those types could come from)

* In VisitTypedefNameDecl, where the `typedef _Atomic(...) atomic_...;`
  declarations of clang's stdatomic.h run through. It's but one of many
  possible callers, but it's the one where one more check can make the
  difference between a usable and a cryptic error for many cases.

Closes: #293
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants