-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Disallow generic type parameters from appearing within certain constants #68356
Disallow generic type parameters from appearing within certain constants #68356
Conversation
…nts. Previously using generic type parameters within array length expressions/enum discriminants caused ICE's or confusing diagnostics.
Some changes occurred in diagnostic error codes |
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
@@ -1,3 +1,4 @@ | |||
// ignore-tidy-filelength |
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 split things in a follow up PR?
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I disagree with doing this in The reason I didn't want this in (there's probably one exception to this, and that would be the For improving errors, I would prefer doing a crater run with this changed to always be rust/src/librustc_typeck/collect.rs Lines 1022 to 1033 in 6250d56
|
This improves the diagonistics/fixes ICEs when generic parameters appear within some constants. For example of the new errors:
Previously emitted confusing errors like:
Note doesn't disallow referring to
Self
in either enum discriminants or array length expressions as there are cases where it can currently be sucessfully used, i.e.:I don't think that this disallows any more code that didn't either produce a compiler error before or caused an ICE.
cc #43408
cc #67945 (doesn't actually fully fix it see: #67945 (comment))