Speed up `Parser::expected_tokens`
The constant pushing/clearing of `Parser::expected_tokens` during parsing is slow. This PR speeds it up greatly.
r? `@estebank`
Make sure we handle `backwards_incompatible_lint` drops appropriately in drop elaboration
In #131326, a new kind of scheduled drop (`drop_kind: DropKind::Value` + `backwards_incompatible_lint: true`) was added so that we could insert a new kind of no-op MIR statement (`backward incompatible drop`) for linting purposes.
These drops were intended to have *no side-effects*, but drop elaboration code forgot to handle these drops specially and they were handled otherwise as normal drops in most of the code. This ends up being **unsound** since we insert more than one drop call for some values, which means that `Drop::drop` could be called more than once.
This PR fixes this by splitting out the `DropKind::ForLint` and adjusting the code. I'm not totally certain if all of the places I've adjusted are either reachable or correct, but I'm pretty certain that it's *more* correct than it was previously.
cc `@dingxiangfei2009`
r? nikomatsakis
Fixes#134482
Remove a duplicated check that doesn't do anything anymore.
fixes#134005
This code didn't actually `lub` the type of the previous expressions, but just the current type over and over again. Changing it to using the actual expression type does not change anything either, so may as well remove the entire loop.
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
Some destructor/drop related tweaks
Two random tweaks I got from investigating some stuff around drops in edition 2024:
1. Use the `TypingEnv` of the mir builder, rather than making it over again.
2. Rename the `id` field from `Scope` to `local_id`, to reflect that it's a local id, and remove the `item_local_id()` accessor which just returned the id field.
Forbid overwriting types in typeck
While trying to figure out some type setting logic in https://github.com/rust-lang/rust/pull/134248 I realized that we sometimes set a type twice. While hopefully that would have been the same type, we didn't ensure that at all and just silently accepted it. So now we reject setting it twice, unless errors are happening, then we don't care.
Best reviewed commit by commit.
No behaviour change is intended.
Variants::Single: do not use invalid VariantIdx for uninhabited enums
~~Stacked on top of https://github.com/rust-lang/rust/pull/133681, only the last commit is new.~~
Currently, `Variants::Single` for an empty enum contains a `VariantIdx` of 0; looking that up in the enum variant list will ICE. That's quite confusing. So let's fix that by adding a new `Variants::Empty` case for types that have 0 variants.
try-job: i686-msvc
cleanup region handling: add `LateParamRegionKind`
The second commit is to enable a split between `BoundRegionKind` and `LateParamRegionKind`, by avoiding `BoundRegionKind` where it isn't necessary.
The third comment then adds `LateParamRegionKind` to avoid having the same late-param region for separate bound regions. This fixes#124021.
r? `@compiler-errors`
In codegen, a used function with `FunctionCoverageInfo` but no mappings has
historically indicated a bug. However, that will no longer be the case after
moving some fallible span-processing steps into codegen.
Currently it relies on having the right integer for every variant, and
if you add a variant you need to adjust the integers for all subsequent
variants, which is a pain.
This commit introduces a match guard formulation that takes advantage of
the enum-to-integer conversion to avoid specifying the integer for each
variant. And it does this via a macro to avoid lots of boilerplate.
The parser pushes a `TokenType` to `Parser::expected_token_types` on
every call to the various `check`/`eat` methods, and clears it on every
call to `bump`. Some of those `TokenType` values are full tokens that
require cloning and dropping. This is a *lot* of work for something
that is only used in error messages and it accounts for a significant
fraction of parsing execution time.
This commit overhauls `TokenType` so that `Parser::expected_token_types`
can be implemented as a bitset. This requires changing `TokenType` to a
C-style parameterless enum, and adding `TokenTypeSet` which uses a
`u128` for the bits. (The new `TokenType` has 105 variants.)
The new types `ExpTokenPair` and `ExpKeywordPair` are now arguments to
the `check`/`eat` methods. This is for maximum speed. The elements in
the pairs are always statically known; e.g. a
`token::BinOp(token::Star)` is always paired with a `TokenType::Star`.
So we now compute `TokenType`s in advance and pass them in to
`check`/`eat` rather than the current approach of constructing them on
insertion into `expected_token_types`.
Values of these pair types can be produced by the new `exp!` macro,
which is used at every `check`/`eat` call site. The macro is for
convenience, allowing any pair to be generated from a single identifier.
The ident/keyword filtering in `expected_one_of_not_found` is no longer
necessary. It was there to account for some sloppiness in
`TokenKind`/`TokenType` comparisons.
The existing `TokenType` is moved to a new file `token_type.rs`, and all
its new infrastructure is added to that file. There is more boilerplate
code than I would like, but I can't see how to make it shorter.
This is a naming convention used in a handful of spots in the parser for
delimiters. It confused me when I first saw it a long time ago, and I've
never liked it. A web search says "Bra-ket notation" exists in linear
algebra but the terminology has zero prior use in a programming context,
as far as I can tell.
This commit changes it to `open`/`close`, which is consistent with the
rest of the compiler.
The most significant is `check_keyword`: it now only pushes to
`expected_token_types` if the keyword check fails, which matches how all
the other `check` methods work.
The remainder are just tweaks to make these methods more consistent with
each other.
Point at lint name instead of whole attr for gated lints
```
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:10
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^
|
= note: the `test_unstable_lint` lint is unstable
= help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
note: the lint level is defined here
--> $DIR/warn-unknown-unstable-lint-inline.rs:3:9
|
LL | #![warn(unknown_lints)]
| ^^^^^^^^^^^^^
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:29
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: the `another_unstable_lint` lint is unstable
= help: add `#![feature(another_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
```
This is particularly relevant when there are multiple lints in the same `warn` attribute. Pointing at the smaller span makes it clearer which one the warning is complaining about.
-Znext-solver: modify candidate preference rules
This implements the design proposed in the FCP in #132325 and matches the old solver behavior. I hope the inline comments are all sufficiently clear, I personally think this is a fairly clear improvement over the existing approach using `fn discard_impls_shadowed_by_env`. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/96.
This also fixes#133639 which encounters an ICE in negative coherence when evaluating the where-clause. Given the features required to trigger this ICE 🤷
r? ``@compiler-errors``
Stabilize `#[diagnostic::do_not_recommend]`
This PR seeks to stabilize the `#[diagnostic::do_not_recommend]`attribute.
This attribute was first proposed as `#[do_not_recommend`] attribute in RFC 2397 (https://github.com/rust-lang/rfcs/pull/2397). It gives the crate authors the ability to not suggest to the compiler to not show certain traits in its error messages.
With the presence of the `#[diagnostic]` tool attribute namespace it was decided to move the attribute there, as that lowers the amount of guarantees the compiler needs to give about the exact way this influences error messages. It turns the attribute into a hint which can be ignored. In addition to the original proposed functionality this attribute now also hides the marked trait in help messages ("This trait is implemented by: ").
The attribute does not accept any argument and can only be placed on trait implementations. If it is placed somewhere else a lint warning is emitted and the attribute is otherwise ignored. If an argument is detected a lint warning is emitted and the argument is ignored. This follows the rules outlined by the diagnostic namespace.
This attribute allows crates like diesel to improve their error messages drastically. The most common example here is the following error message:
```
error[E0277]: the trait bound `&str: Expression` is not satisfied
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
|
= help: the following other types implement trait `Expression`:
Bound<T>
SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
|
LL | impl<T, ST> AsExpression<ST> for T
| ^^^^^^^^^^^^^^^^ ^
LL | where
LL | T: Expression<SqlType = ST>,
| ------------------------ unsatisfied trait bound introduced here
```
By applying the new attribute to the wild card trait implementation of
`AsExpression` for `T: Expression` the error message becomes:
```
error[E0277]: the trait bound `&str: AsExpression<Integer>` is not satisfied
--> $DIR/as_expression.rs:55:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `AsExpression<Integer>` is not implemented for `&str`
|
= help: the trait `AsExpression<Text>` is implemented for `&str`
= help: for that trait implementation, expected `Text`, found `Integer`
```
which makes it much easier for users to understand that they are facing a type mismatch.
Other explored example usages include:
* This standard library error message: https://github.com/rust-lang/rust/pull/128008
* That bevy derived example:
e1f3068995/tests/ui/diagnostic_namespace/do_not_recommend/supress_suggestions_in_help.rs (No
more tuple pyramids)
Fixes#51992
r? ``@compiler-errors``
This PR also adds a few more tests, makes sure that all the tests are run for the old and new trait solver and adds a check that the attribute does not contain arguments.
```
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:10
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^
|
= note: the `test_unstable_lint` lint is unstable
= help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
note: the lint level is defined here
--> $DIR/warn-unknown-unstable-lint-inline.rs:3:9
|
LL | #![warn(unknown_lints)]
| ^^^^^^^^^^^^^
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:29
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: the `test_unstable_lint` lint is unstable
= help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
note: the lint level is defined here
--> $DIR/warn-unknown-unstable-lint-inline.rs:3:9
|
LL | #![warn(unknown_lints)]
| ^^^^^^^^^^^^^
```
This is particularly relevant when there are multiple lints in the same `warn` attribute. Pointing at the smaller span makes it clearer which one the warning is complaining about.
Use field init shorthand where possible
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
EDIT: this PR also updates `rustfmt.toml` to set
`use_field_init_shorthand = true`.
Merge some patterns together
just something I noticed while browsing code. No change in functionality, deduplicates the 100% equal match arms by creating one big or pattern
Do not do if ! else, use unnegated cond and swap the branches instead
I'm tidying up my ergonomic ref counting PR and I'm going to make some small, simple and unrelated changes outside that PR, so the main PR sticks more straight to the point.
Clarify the match ergonomics 2024 migration lint's output
This makes a few changes:
- Rather than using the whole pattern as a span for the lint, this collects spans for each problematic default binding mode reset and labels them with why they're problems.
- The lint's suggestions are now verbose-styled, so that it's clear what's being suggested vs. what's problematic.
- The wording is now less technical, and the hard error version of this diagnostic now links to the same reference material as the lint (currently an unwritten page of the edition guide).
I'm not totally confident in the wording or formatting, so I'd appreciate feedback on that in particular. I tried to draw a connection with word choice between the labels and the suggestion, but it might be imprecise, unclear, or cluttered. If so, it might be worth making the labels more terse and adding notes that explain them, but that's harder to read in a way too.
cc ```@Nadrieril``` ```@Jules-Bertholet```
Closes#133854. For reference, the error from that issue becomes:
```
error: pattern uses features incompatible with edition 2024
--> $DIR/remove-me.rs:6:25
|
LL | map.iter().filter(|(&(_x, _y), &_c)| false);
| ^ ^ cannot implicitly match against multiple layers of reference
| |
| cannot implicitly match against multiple layers of reference
|
help: make the implied reference pattern explicit
|
LL | map.iter().filter(|&(&(_x, _y), &_c)| false);
| +
```
Overhaul keyword handling
The compiler's list of keywords has some problems.
- It contains several items that aren't keywords.
- The order isn't quite right in a couple of places.
- Some of the names of predicates relating to keywords are confusing.
- rustdoc and rustfmt have their own (incorrect) versions of the keyword list.
- `AllKeywords` is unnecessarily complex.
r? ```@jieyouxu```
