-
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
Suggest adding { .. }
around more bad const generic exprs
#92884
Suggest adding { .. }
around more bad const generic exprs
#92884
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
that's really nice ✨ gj |
This comment was marked as resolved.
This comment was marked as resolved.
nvm, let's try r? rust-lang/compiler |
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.
One nit, then r=me
@bors delegate+ |
✌️ @compiler-errors can now approve this pull request |
f3be3b4
to
6b52ac2
Compare
@bors r=jackh726 |
📌 Commit 6b52ac2 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7c3331c): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Recover from more const arguments that are not wrapped in curly braces Recover from some array, borrow, tuple & arithmetic expressions in const argument positions that lack curly braces and provide a suggestion to fix the issue continuing where rust-lang#92884 left off. Examples of such expressions: `[]`, `[0]`, `[1, 2]`, `[0; 0xff]`, `&9`, `("", 0)` and `(1 + 2) * 3` (we previously did not recover from them). I am not entirely happy with my current solution because the code that recovers from `[0]` (coinciding with a malformed slice type) and `[0; 0]` (coinciding with a malformed array type) is quite fragile as the aforementioned snippets are actually successfully parsed as types by `parse_ty` since it itself already recovers from them (returning `[⟨error⟩]` and `[⟨error⟩; 0]` respectively) meaning I have to manually look for `TyKind::Err`s and construct a separate diagnostic for the suggestion to attach to (thereby emitting two diagnostics in total). Fixes rust-lang#81698. `@rustbot` label A-diagnostics r? diagnostics
Fixes #92776