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.
Revert "Remove `checked_add` in `Layout::repeat`"
This fixes a a segfault in safe code, a stable regression. Reported in #69225.
This reverts commit a983e0590a.
This fixes a a segfault in safe code, a stable regression. Reported in
\#69225.
This reverts commit a983e0590a.
Also adds a test for the expected behaviour.
Do not emit note suggesting to implement operation trait to foreign type
When a binary operation isn't valid, you will get a lint proposing to add a trait implementation to make the operation possible. However, this cannot be done for foreign types, such as types from `core` or `std`.
For example:
```
= note: an implementation of `std::ops::Add` might be missing for `std::option::Option<i8>`
```
As mentioned in https://github.com/rust-lang/rust/issues/60497#issuecomment-562665539:
> The note suggesting implementing Add<i8> should only be emitted if Option<i8> were local to the current crate, which it isn't, so in this case it shouldn't be emitted.
(I will use the CI to check tests for me, or my computer will just burn... and running IDEs is not possible on a pile of ashes)
r? @estebank
parser: Simplify treatment of macro variables in `Parser::bump`
Follow-up to https://github.com/rust-lang/rust/pull/69006.
Token normalization for `$ident` and `$lifetime` is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling (as a result `bump` also doesn't call itself recursively anymore and can't make `prev_token` inconsistent).
r? @Centril
parse: fuse associated and extern items up to defaultness
Language changes:
- The grammar of extern `type` aliases is unified with associated ones, and becomes:
```rust
TypeItem = "type" ident generics {":" bounds}? where_clause {"=" type}? ";" ;
```
Semantic restrictions (`ast_validation`) are added to forbid any parameters in `generics`, any bounds in `bounds`, and any predicates in `where_clause`, as well as the presence of a type expression (`= u8`).
(Work still remains to fuse this with free `type` aliases, but this can be done later.)
- The grammar of constants and static items (free, associated, and extern) now permits the absence of an expression, and becomes:
```rust
GlobalItem = {"const" {ident | "_"} | "static" "mut"? ident} {"=" expr}? ";" ;
```
- A semantic restriction is added to enforce the presence of the expression (the body).
- A semantic restriction is added to reject `const _` in associated contexts.
Together, these changes allow us to fuse the grammar of associated items and extern items up to `default`ness which is the main goal of the PR.
-----------------------
We are now very close to fully fusing the entirely of item parsing and their ASTs. To progress further, we must make a decision: should we parse e.g. `default use foo::bar;` and whatnot? Accepting that is likely easiest from a parsing perspective, as it does not require using look-ahead, but it is perhaps not too onerous to only accept it for `fn`s (and all their various qualifiers), `const`s, `static`s, and `type`s.
r? @petrochenkov
Token normalization is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling.
miri: improve and simplify overflow detection
This simplifies the overflow detection for signed binary operators, and adds overflow detection to unary operators so that const-prop doesn't have to crudely hand-roll that.
It also fixes some bugs in the operator implementation that however, I think, were not observable.
r? @oli-obk @wesleywiser
Improve reporting errors and suggestions for trait bounds
Fix#66802
- When printing errors for unsized function parameter, properly point at the parameter instead of function's body.
- Improve `consider further restricting this bound` (and related) messages by separating human-oriented hints from the machine-oriented ones.
When suggesting associated fn with type parameters, include in the structured suggestion
Address #50734.
```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
--> file.rs:14:1
|
14 | impl TraitA<()> for S {
| ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
|
= help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
= help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
= help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```
It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.
Initial implementation of `#![feature(move_ref_pattern)]`
Following up on #45600, under the gate `#![feature(move_ref_pattern)]`, `(ref x, mut y)` is allowed subject to restrictions necessary for soundness. The match checking implementation and tests for `#![feature(bindings_after_at)]` is also adjusted as necessary.
Closes#45600.
Tracking issue: #68354.
r? @matthewjasper
Towards unified `fn` grammar
Part of https://github.com/rust-lang/rust/pull/68728.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.
r? @petrochenkov
Account for HR lifetimes when suggesting introduction of named lifetime
```
error[E0106]: missing lifetime specifier
--> src/test/ui/suggestions/fn-missing-lifetime-in-item.rs:2:32
|
2 | struct S2<F: Fn(&i32, &i32) -> &i32>(F);
| ---- ---- ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
= note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html
help: consider making the bound lifetime-generic with a new `'a` lifetime
|
2 | struct S2<F: for<'a> Fn(&'a i32, &'a i32) -> &'a i32>(F);
| ^^^^^^^ ^^^^^^^ ^^^^^^^ ^^^
help: consider introducing a named lifetime parameter
|
2 | struct S2<'a, F: Fn(&'a i32, &'a i32) -> &'a i32>(F);=
| ^^^ ^^^^^^^ ^^^^^^^ ^^^
```
Follow up to #68267. Addresses the diagnostics part of #49287.
