Improve expression & attribute parsing
This PR includes misc improvements to expression and attribute parsing.
1. Some code simplifications
2. Better recovery for various block forms, e.g. `loop statements }` (missing `{` after `loop`). (See e.g., `block-no-opening-brace.rs` among others for examples.)
3. Added recovery for e.g., `unsafe $b` where `$b` refers to a `block` macro fragment. (See `bad-interpolated-block.rs` for examples.)
4. ^--- These are done so that code sharing in block parsing is increased.
5. Added recovery for e.g., `'label: loop { ... }` (See `labeled-no-colon-expr.rs`.)
6. Added recovery for e.g., `&'lifetime expr` (See `regions-out-of-scope-slice.rs`.)
7. Added recovery for e.g., `fn foo() = expr;` (See `fn-body-eq-expr-semi.rs`.)
8. Simplified attribute parsing code & slightly improved diagnostics.
9. Added recovery for e.g., `Box<('a) + Trait>`.
10. Added recovery for e.g, `if true #[attr] {} else #[attr] {} else #[attr] if true {}`.
r? @estebank
When encountering an Item in a pat context, point at the item def
```
error[E0308]: mismatched types
--> $DIR/const-in-struct-pat.rs:8:17
|
LL | struct foo;
| ----------- `foo` defined here
...
LL | let Thing { foo } = t;
| ^^^ expected struct `std::string::String`, found struct `foo`
|
= note: `foo` is interpreted as a unit struct, not a new binding
help: you can bind the struct field to a different name
|
LL | let Thing { foo: other_foo } = t;
| ^^^^^^^^^^^^^^
```
```
error[E0308]: mismatched types
--> $DIR/const.rs:14:9
|
LL | const FOO: Foo = Foo{bar: 5};
| ----------------------------- constant defined here
...
LL | FOO => {},
| ^^^
| |
| expected `&Foo`, found struct `Foo`
| `FOO` is interpreted as a constant, not a new binding
| help: use different name to introduce a new binding: `other_foo`
```
Fix#55631, fix#48062, cc #42876.
`delay_span_bug` when codegen cannot select obligation
Fix#69602, introduced in #60126 by letting the compiler continue past
type checking after encountering errors.
When the obligation that couldn't be fulfilled is specific to a nested
obligation, maintain both the nested and parent obligations around for
more accurate and detailed error reporting.
Surface associated type projection bounds that could not be fulfilled in
E0599 errors. Always present the list of unfulfilled trait bounds,
regardless of whether we're pointing at the ADT or trait that didn't
satisfy it.
parser: `token` -> `normalized_token`, `nonnormalized_token` -> `token`
So, after https://github.com/rust-lang/rust/pull/69006, its follow-ups and an attempt to remove `Parser::prev_span` I came to the conclusion that the unnormalized token and its span is what you want in most cases, so it should be default.
Normalization only makes difference in few cases where we are checking against `token::Ident` or `token::Lifetime` specifically.
This PR uses `normalized_token` for those cases.
Using normalization explicitly means that people writing code should remember about `NtIdent` and `NtLifetime` in general. (That is alleviated by the fact that `token.ident()` and `fn parse_ident_*` are already written.)
Remembering about `NtIdent`, was, however, already the case, kind of, because the implicit normalization was performed only for the current/previous token, but not for things like `look_ahead`.
As a result, most of token classification methods in `token.rs` already take `NtIdent` into account (this PR fixes a few pre-existing minor mistakes though).
The next step is removing `normalized(_prev)_token` entirely and replacing it with `token.ident()` (mostly) and `token.normalize()` (occasionally).
I want to make it a separate PR for that and run it though perf.
`normalized_token` filled on every bump has both a potential to avoid repeated normalization, and to do unnecessary work in advance (it probably doesn't matter anyway, the normalization is very cheap).
r? @Centril
instantiate_value_path: on `SelfCtor`, avoid unconstrained tyvars
Fixes https://github.com/rust-lang/rust/issues/69306.
On `Self(...)` (that is, a `Res::SelfCtor`), do not use `self.impl_self_ty(...)`. The problem with that method is that it creates unconstrained inference variables for type parameters in the `impl` (e.g. `impl<T> S0<T>`). These variables then eventually get substituted for something else when they come in contact with the expected type (e.g. `S0<u8>`) or merely the arguments passed to the tuple constructor (e.g. the `0` in `Self(0)`).
Instead of using `self.impl_self_ty(...)`, we instead merely use `let ty = self.normalize_ty(span, tcx.at(span).type_of(impl_def_id));` to get the rewritten `res`.
r? @eddyb
Generalized article_and_description
r? @matthewjasper
The logic of finding the right word and article to print seems to be repeated elsewhere... this is an experimental method to unify this logic...
Unify and improve const-prop lints
Add a single helper method for all lints emitted by const-prop, and make that lint different from the CTFE `const_err` lint. Also consistently check overflow on *arithmetic*, not on the assertion, to make behavior the same for debug and release builds.
See [this summary comment](https://github.com/rust-lang/rust/pull/69185#issuecomment-587924754) for details and the latest status.
In terms of lint formatting, I went for what seems to be the better style: have a general message above the code, and then a specific message at the span:
```
error: this arithmetic operation will overflow
--> $DIR/const-err2.rs:21:18
|
LL | let a_i128 = -std::i128::MIN;
| ^^^^^^^^^^^^^^^ attempt to negate with overflow
```
We could also just have the specific message above and no text at the span if that is preferred.
I also converted some of the existing tests to use compiletest revisions, so that the same test can check a bunch of different compile flags.
Fixes https://github.com/rust-lang/rust/issues/69020.
Helps with https://github.com/rust-lang/rust/issues/69021: debug/release are now consistent, but the assoc-const test in that issue still fails (there is a FIXME in the PR for this). The reason seems to be that const-prop notices the assoc const in `T::N << 42` and does not even bother calling `const_prop` on that operation.
Has no effect on https://github.com/rust-lang/rust/issues/61821; the duplication there has entirely different reasons.
Remove special case for `simd_shuffle` arg promotion
After rust-lang/stdarch#825, these intrinsics are now defined with `#[rustc_args_required_const(2)]`, so the special-case is no longer necessary.
