| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Try to recover from a `=>` -> `=` or `->` typo in a match arm
Fixes #89396.
|
|
Consistently use 'supertrait'.
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
|
|
|
|
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
|
|
|
|
|
|
Fix error recovery in format macro parsing
Fixes #88770. Basically, the assumption in the following comment is incorrect:
https://github.com/rust-lang/rust/blob/b69fe57261086e70aea9d5b58819a1794bf7c121/compiler/rustc_builtin_macros/src/format.rs#L167-L172
This is only true in the first iteration of the loop, when [`p.clear_expected_tokens()`](https://github.com/rust-lang/rust/blob/b69fe57261086e70aea9d5b58819a1794bf7c121/compiler/rustc_builtin_macros/src/format.rs#L164) is called. In subsequent iterations, `p.expected_tokens` won't be empty, so `p.expect()` won't actually call `unexpected_try_recover()`:
https://github.com/rust-lang/rust/blob/b69fe57261086e70aea9d5b58819a1794bf7c121/compiler/rustc_parse/src/parser/mod.rs#L487-L498
Instead, it will call `expect_one_of()`, which _can_ recover and return `Ok()`. This PR handles this case to fix the ICE in #88770.
|
|
"Fix" an overflow in byte position math
r? `@estebank`
help! I fixed the ICE only to brick the diagnostic.
I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
|
|
Print a note if a character literal contains a variation selector
Fixes #88684.
|
|
|
|
|
|
|
|
Recover from `Foo(a: 1, b: 2)`
Detect likely `struct` literal using parentheses as delimiters and emit
targeted suggestion instead of type ascription parse error.
Fix #61326.
|
|
Revert anon union parsing
Revert PR #84571 and #85515, which implemented anonymous union parsing in a manner that broke the context-sensitivity for the `union` keyword and thus broke stable Rust code.
Fix #88583.
|
|
Accept `m!{ .. }.method()` and `m!{ .. }?` statements.
This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`:
Before:
```
error: expected expression, found `.`
--> src/lib.rs:6:6
|
4 | quote! {
5 | ...
6 | }.into()
| ^ expected expression
```
After:
```
```
(No output, compiles fine.)
---
Context:
For expressions like `{ 1 }` and `if true { 1 } else { 2 }`, we accept them as full statements without a trailing `;`, which means the following is not accepted:
```rust
{ 1 } - 1 // error
```
since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct, but the type of `{ 1 }` should be `()` as there is no `;`.
However, for specifically `.` and `?` after the `}`, we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876):
```rust
{ "abc" }.len(); // ok
```
For braced macro invocations, we do not do this:
```rust
vec![1, 2, 3].len(); // ok
vec!{1, 2, 3}.len(); // error
```
(It parses `vec!{1, 2, 3}` as a full statement, and then complains about `.len()` not being a valid expression.)
This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases, since no statement can start with a `.` or `?`.
|
|
Rollup of 7 pull requests
Successful merges:
- #88033 (Add links for primitives in "jump to definition" feature)
- #88722 (Make `UnsafeCell::get_mut` const)
- #88851 (Fix duplicate bounds for const_trait_impl)
- #88859 (interpreter PointerArithmetic: use new Size helper methods)
- #88885 (Fix jump def background)
- #88894 (Improve error message for missing trait in trait impl)
- #88896 (Reduce possibility of flaky tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use smaller spans for some structured suggestions
Use more accurate suggestion spans for
* argument parse error
* fully qualified path
* missing code block type
* numeric casts
|
|
|
|
|
|
Suggest wapping expr in parentheses on invalid unary negation
Fixes #88701
|
|
|
|
|
|
|
|
Improve diagnostics for unary plus operators (#88276)
This pull request improves the diagnostics emitted on parsing a unary plus operator. See #88276.
Before:
```
error: expected expression, found `+`
--> src/main.rs:2:13
|
2 | let x = +1;
| ^ expected expression
```
After:
```
error: leading `+` is not supported
--> main.rs:2:13
|
2 | let x = +1;
| ^
| |
| unexpected `+`
| help: try removing the `+`
```
|
|
Detect likely `struct` literal using parentheses as delimiters and emit
targeted suggestion instead of type ascription parse error.
Fix #61326.
|
|
Fixes #88701
|
|
|
|
Provide more context on incorrect inner attribute
Suggest changing an inner attribute into an outer attribute if followed by an item.
|
|
|
|
Point at unclosed delimiters as part of the primary MultiSpan
Both the place where the parser encounters a needed closed delimiter and
the unclosed opening delimiter are important, so they should get the
same level of highlighting in the output.
_Context: https://twitter.com/mwk4/status/1430631546432675840_
|
|
Suggest changing an inner attribute into an outer attribute if followed by an item.
|
|
|
|
Introduce `let...else`
Tracking issue: #87335
The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.
Overall, I believe this PR is feature-complete with regard to the RFC.
|
|
|
|
Old error output:
3 | let _: usize = $f;
| ----- ^ expected `usize`, found struct `Baz`
| |
| expected due to this
New error output:
3 | let _: usize = $f;
| ----- ^^ expected `usize`, found struct `Baz`
| |
| expected due to this
|
|
Old error output:
= note: this warning originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info)
help: wrap this expression in parentheses
|
4 | break '_l $f(;)
| ^ ^
New error output:
= note: this warning originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info)
help: wrap this expression in parentheses
|
4 | break '_l ($f);
| ^ ^
|
|
Both the place where the parser encounters a needed closed delimiter and
the unclosed opening delimiter are important, so they should get the
same level of highlighting in the output.
|
|
|
|
Stabilize `arbitrary_enum_discriminant`
Closes #60553.
----
## Stabilization Report
_copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_
### Summary
Enables a user to specify *explicit* discriminants on arbitrary enums.
Previously, this was hard to achieve:
```rust
#[repr(u8)]
enum Foo {
A(u8) = 0,
B(i8) = 1,
C(bool) = 42,
}
```
Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants.
In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md), this feature would provide more flexibility for FFI and unsafe code involving enums.
### Test cases
Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant), there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete).
### Edge cases
The feature is well defined and does not have many edge cases.
One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved.
### Previous PRs
The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book, https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639.
### Resolution of unresolved questions
The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271.
----
(someone please add `needs-fcp`)
|
|
Link to edition guide instead of issues for 2021 lints.
This changes the 2021 lints to not link to github issues, but to the edition guide instead.
Fixes #86996
|
|
Use more accurate suggestion spans for
* argument parse error
* fully qualified path
* missing code block type
* numeric casts
* E0212
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
|
|
Improve diagnostics for wrongly ordered keywords in function declaration
Fix #87217
`@rustbot` label A-diagnostics T-compiler
|
|
Remove unnecessary trailing whitespace from error messages
Some error messages currently contain unnecessary trailing whitespace. There are some legitimate reasons for having trailing whitespace in the output, such as for uniform indentation of possibly-empty input lines, but the whitespace I have addressed here occurs in a line used only for spacing, and I see no reason why that should have trailing whitespace (spacing lines inserted in other places also don't have trailing whitespace).
I have also removed a superfluous call to `buffer.putc()`, which has no effect because the same character is already placed there by `draw_col_separator()`.
Use `git diff --ignore-space-at-eol` to see my changes; otherwise the diff is quite large due to the whitespace removed from expected outputs in `src/test/ui/`.
|
|
|
|
Allow labeled loops as value expressions for `break`
Fixes #86948. This is currently allowed:
```rust
return 'label: loop { break 'label 42; };
break ('label: loop { break 'label 42; });
break 1 + 'label: loop { break 'label 42; };
break 'outer 'inner: loop { break 'inner 42; };
```
But not this:
```rust
break 'label: loop { break 'label 42; };
```
I have fixed this, so that the above now parses as an unlabeled break with a labeled loop as its value expression.
|
|
|
|
Fix a parser ICE on invalid `fn` body
Fixes #87635
A better fix would add a check for `fn` body on `expected_one_of_not_found` but I haven't come up with a graceful way. Any idea?
r? ```@oli-obk``` ```@estebank```
|
