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

Aro translate c: Render error diagnostics properly and ignore _Static_assert decls during translation #20865

Merged
merged 3 commits into from
Jul 29, 2024

Conversation

ehaas
Copy link
Contributor

@ehaas ehaas commented Jul 29, 2024

Note: this only ignores _Static_assert during translation, which matches the behavior of clang-based translate-c. The _Static_assert conditions are validated during parsing and any failures result in an error.

Previously we were not rendering errors and exiting with a non-zero status. I wasn't sure how to add a test for this to the existing translate-c tests but I tested manually with:
./stage3/bin/zig run -fno-clang -fno-llvm -fno-lld --dep aro -Mroot=../lib/compiler/aro_translate_c.zig -Maro=../lib/compiler/aro/aro.zig -- ~/test.c

test.c contents:

_Static_assert(1 == 2, "Bad comparison");

Output:

/Users/ehaas/test.c:1:1: error: static assertion failed "Bad comparison"
_Static_assert(1 == 2, "Bad comparison");
^

The error count is not set until the diagnostics are actually rendered
This does not completely ignore static asserts - they are validated by aro
during parsing; any failures will render an error and non-zero exit code.

Emit a warning comment that _Static_asserts are not translated - this
matches the behavior of the existing clang-based translate-c.

Aro currently does not store source locations for _Static_assert
declarations so I've hard-coded token index 0 for now.
/// Renders errors and fatal errors + associated notes (e.g. "expanded from here"); does not render warnings or associated notes
/// Terminates with exit code 1
fn renderErrorsAndExit(comp: *aro.Compilation) noreturn {
defer std.process.exit(1);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe/valid to have a defer which runs after control flow reaches the end of a noreturn function or is this too clever?

Copy link
Contributor

@rohlem rohlem Jul 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

defer statements run at the end of the current block, so afaiu the language has to allow it if you added another block scope encompassing the entire function body (that block would then be void instead of noreturn).
I'm not sure how much the compiler would gain by requiring this extra step of users, so I wouldn't see a point in disallowing it as-is.

@andrewrk andrewrk enabled auto-merge July 29, 2024 20:01
@andrewrk andrewrk merged commit d60c100 into ziglang:master Jul 29, 2024
10 checks passed
@ehaas ehaas deleted the aro-translate-c-static-assert branch July 29, 2024 22:32
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 this pull request may close these issues.

3 participants