-
Notifications
You must be signed in to change notification settings - Fork 254
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
Comments
The C11 (Also, please note that you must use the rust nightly version in |
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 exampleAs for minimal example, this is how I've managed to produce errors like the above:
[{
"arguments": ["any-cc", "test.c"],
"file": "test.c",
"directory": "/tmp/minimal-transpile-example/"
}]
#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. WorkaroundThis exercise has led me to see that adding a |
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 I'll treat this issue as revolving around the steps of how to get into a regular |
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
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
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
stdatomic.h
raises missing types for AstNode { ... __ATOMIC_SEQ_CST }
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
Whenever c2rust encounters stdatomic.h in my setup, it fails irrecoverably with messages like this:
(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.)The text was updated successfully, but these errors were encountered: