-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Improve the help message for an invalid calling convention #100488
Improve the help message for an invalid calling convention #100488
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure how to check stability
I'm not sure either, but I'd suggest compiling a crate with an unstable ABI and using -Ztreat-err-as-bug to see where the error is reported. Then you can use that same logic in the diagnostics code :)
the .map(|s| Symbol::intern(s)).collect::<Vec<_>>() seems pretty gross performance-wise, but maybe that's OK in error reporting code.
Yeah, that's fine, error reporting doesn't care about performance.
CallingConventions => { | ||
let mut calling_conventions = rustc_target::spec::abi::all_names(); | ||
calling_conventions.sort_unstable(); | ||
println!("{}", calling_conventions.join("\n")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also add a UI test for this flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm not finding any tests for other --print options, e.g. --print=target-list has extremely similar code to this one. Could you point out where those are so I can add this test alongside them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, not sure off the top of my head. Maybe it's in run-make
? If I were at a laptop I'd find this with grep -r -- --print src/test
, but I'm on mobile right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah thanks! Found this, but it's a bit odd as there seems to be no expected output. I'll add a similar Makefile for calling-conventions
. https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/print-target-list
Hmm. The errors seem to be reported here
The crate rustc_ast_passes is not available in rustc_ast_lowering. Should I add a reference? Also, I'm not sure how to call that function without reporting an error - do I need to construct a dummy Session or something like that? How do I do that? |
I'd suggest taking that giant match and refactoring it a bit - add a public function in rustc_ast_lowering that only determines whether the ABI is unstable or not, then calling it from the feature gate code in rustc_ast_passes. Then you don't need a dummy session and you can make sure the diagnostic code uses the same logic as the feature gate code. |
9edf69a
to
fb426cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great :) I'll let a compiler member review since I don't often touch target specs, but the code LGTM.
Unrecognized, | ||
} | ||
|
||
macro_rules! gate_feature_post { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I would change this from a macro to a function, since it no longer affects control flow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one slight annoyance with that is that $feature
is used in both $features.$feature
(bool field for if it's enabled), as well as sym::$feature
, so the caller would have to duplicate the name of the feature, passing in both. I guess that's okay, though, and probably worth it being a regular function over a macro?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I agree changing it is a pain. But I also kind of feel that if this is a macro, it's not helping enough for it to be worth it - it would be nice to find a way to simplify the giant match some more, e.g. only pass in a list of ABI names and feature gates and have it generate the match for you.
That said, it's a big change unrelated to your improvement, I'm fine with just merging as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah! @m-ou-se pointed out that Features::enabled(Symbol)
exists, that makes it nicer.
☔ The latest upstream changes (presumably #101064) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great!
-include ../tools.mk | ||
|
||
all: | ||
$(RUSTC) --print calling-conventions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, wouldn’t this be better off as a UI test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure - I'm following the example set by other similar tests. If we want to change the group of them to test in a different way, that seems like a separate change IMO #100488 (comment)
r=me in that regard. This needs a rebase and this could probably benefit from fewer commits (e.g. squash in the commits that fix mistakes introduced by prior commits as well as those that add tests) |
I'm not sure how to resolve the merge conflict from 0043d10, to be honest. I don't know how this new error reporting system works, or what this .ftl file is. Is there any documentation on how this extremely magical-seeming system works, so I can use it properly? (macros are one thing, this seems like a whole custom DSL, haha) @JeanCASPAR do you think you could help out? |
cc @davidtwco , is there documentation somewhere for how to use the translation macros? |
https://rustc-dev-guide.rust-lang.org/diagnostics/diagnostic-structs.html primarily, #100717 links most of our resources |
45ea9a6
to
c46abb6
Compare
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki |
Sorry for taking so long for the update! @nagisa could I get another review? I (...we) changed some stuff in the rebase, it might be nice to check again. Thanks! |
☔ The latest upstream changes (presumably #101558) made this pull request unmergeable. Please resolve the merge conflicts. |
c46abb6
to
9a206a7
Compare
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (77e7e88): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
Fixes #93601
I mostly followed the suggestions of @nagisa in that issue,
however, I wasn't sure how to check stability for the suggestion of "Do not suggest CCs that cannot be used due to them being unstable and feature not being enabled", so I did not implement that point.I haven't contributed to rustc much, please feel free to point out suggestions! For example, the
.map(|s| Symbol::intern(s)).collect::<Vec<_>>()
seems pretty gross performance-wise, but maybe that's OK in error reporting code.