Encode spans relative to the enclosing item
The aim of this PR is to avoid recomputing queries when code is moved without modification.
MCP at https://github.com/rust-lang/compiler-team/issues/443
This is achieved by :
1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation.
Since all client code uses `Span`, step 3 ensures that all manipulations
of span byte positions actually create the dependency edge between
the caller and the `source_span(LocalDefId)`.
This query return the actual absolute span of the parent item.
As a consequence, any source code motion that changes the absolute byte position of a node will either:
- modify the distance to the parent's beginning, so change the relative span's hash;
- dirty `source_span`, and trigger the incremental recomputation of all code that
depends on the span's absolute byte position.
With this scheme, I believe the dependency tracking to be accurate.
For the moment, the spans are marked during lowering.
I'd rather do this during def-collection,
but the AST MutVisitor is not practical enough just yet.
The only difference is that we attach macro-expanded spans
to their expansion point instead of the macro itself.
As reported in issue #77175, the opaque type generated by the desugaring process of an async function uses the lifetimes defined by the originating function. The definition ID for the lifetimes in the opaque method is different from the one in the originating async function and it could therefore be considered a single use of the lifetimne, this causes the single_use_lifetimes lint to fail compilation if explicitly denied. This fix skips the lint for lifetimes used only once in generated opaque types for an async function that are declared in the parent async function definition.
Detect bare blocks with type ascription that were meant to be a `struct` literal
Address part of #34255.
Potential improvement: silence the other knock down errors in `issue-34255-1.rs`.
Remove `Session.if_let_suggestions`
We can instead if either the LHS or RHS types contain
`TyKind::Error`. In addition to covering the case where
we would have previously updated `if_let_suggestions`, this might
also prevent redundant errors in other cases as well.
We can instead if either the LHS or RHS types contain
`TyKind::Error`. In addition to covering the case where
we would have previously updated `if_let_suggestions`, this might
also prevent redundant errors in other cases as well.
Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`
Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).
`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`
Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.
We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.
With this commit, a large source of global untracked state is removed.
Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.
This adds notes like:
```
error: cannot find derive macro `Serialize` in this scope
--> $DIR/issue-88206.rs:22:10
|
LL | #[derive(Serialize)]
| ^^^^^^^^^
|
note: `Serialize` is imported here, but it is not a derive macro
--> $DIR/issue-88206.rs:17:11
|
LL | use hey::{Serialize, Deserialize};
| ^^^^^^^^^
```
Fixes https://github.com/rust-lang/rust/issues/88206
Includes https://github.com/rust-lang/rust/pull/88229
r? `@estebank`
Stop tracking namespace in used_imports.
This changes `used_imports` from a `FxHashSet<(NodeId, Namespace)>` to a `FxHashSet<NodeId>`, as the Namespace information isn't used.
The only point that uses it did three lookups, `|=`'ing them together.
r? `@estebank`
Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).
`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`
Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.
We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.
With this commit, a large source of global untracked state is removed.
When we need to emit a lint at a macro invocation, we currently use the
`NodeId` of its parent definition (e.g. the enclosing function). This
means that any `#[allow]` / `#[deny]` attributes placed 'closer' to the
macro (e.g. on an enclosing block or statement) will have no effect.
This commit computes a better `lint_node_id` in `InvocationCollector`.
When we visit/flat_map an AST node, we assign it a `NodeId` (earlier
than we normally would), and store than `NodeId` in current
`ExpansionData`. When we collect a macro invocation, the current
`lint_node_id` gets cloned along with our `ExpansionData`, allowing it
to be used if we need to emit a lint later on.
This improves the handling of `#[allow]` / `#[deny]` for
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` and some `asm!`-related lints.
The 'legacy derive helpers' lint retains its current behavior
(I've inlined the now-removed `lint_node_id` function), since
there isn't an `ExpansionData` readily available.
Fix use placement for suggestions near main.
This fixes an edge case for the suggestion to add a `use`. When running with `--test`, the `main` function will be annotated with an `#[allow(dead_code)]` attribute. The `UsePlacementFinder` would end up using the dummy span of that synthetic attribute. If there are top-level inner attributes, this would place the `use` in the wrong position. The solution here is to ignore attributes with dummy spans.
In the process of working on this, I discovered that the `use_suggestion_placement` test was broken. `UsePlacementFinder` is unaware of active attributes. Attributes like `#[derive]` don't exist in the AST since they are removed. Fixing that is difficult, since the AST does not retain enough information. I considered trying to place the `use` towards the top of the module after any `extern crate` items, but I couldn't find a way to get a span for the start of a module block (the `mod` span starts at the `mod` keyword, and it seems tricky to find the spot just after the opening bracket and past inner attributes). For now, I just put some comments about the issue. This appears to have been a known issue in #44215 where the test for it was introduced, and the fix seemed to be deferred to later.
Don't use a generator for BoxedResolver
The generator is non-trivial and requires unsafe code anyway. Using regular unsafe code without a generator is much easier to follow.
Based on #85810 as it touches rustc_interface too.
Disallow shadowing const parameters
This pull request fixes#85348. Trying to shadow a `const` parameter as follows:
```rust
fn foo<const N: i32>() {
let N @ _ = 0;
}
```
currently causes an ICE. With my changes, I get:
```
error[E0530]: let bindings cannot shadow const parameters
--> test.rs:2:9
|
1 | fn foo<const N: i32>() {
| - the const parameter `N` is defined here
2 | let N @ _ = 0;
| ^ cannot be named the same as a const parameter
error: aborting due to previous error
```
This is the same error you get when trying to shadow a constant:
```rust
const N: i32 = 0;
let N @ _ = 0;
```
```
error[E0530]: let bindings cannot shadow constants
--> src/lib.rs:3:5
|
2 | const N: i32 = 0;
| ----------------- the constant `N` is defined here
3 | let N @ _ = 0;
| ^ cannot be named the same as a constant
error: aborting due to previous error
```
The reason for disallowing shadowing in both cases is described [here](https://github.com/rust-lang/rust/issues/33118#issuecomment-233962221) (the comment there only talks about constants, but the same reasoning applies to `const` parameters).
Fix diagnostic for cross crate private tuple struct constructors
Fixes#78708.
There was already some limited support for certain cross-crate scenarios but that didn't handle a tuple struct rexported from an inner module for example (e.g. the NonZero* types as seen in #85049).
```Rust
➜ cat bug.rs
fn main() {
let _x = std::num::NonZeroU32(12);
let n = std::num::NonZeroU32::new(1).unwrap();
match n {
std::num::NonZeroU32(i) => {},
}
}
```
**Before:**
<details>
```Rust
➜ rustc +nightly bug.rs
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::num::NonZeroU32`
--> bug.rs:2:14
|
2 | let _x = std::num::NonZeroU32(12);
| ^^^^^^^^^^^^^^^^^^^^^^^^ help: use struct literal syntax instead: `std::num::NonZeroU32 { 0: val }`
|
::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: expected tuple struct or tuple variant, found struct `std::num::NonZeroU32`
--> bug.rs:5:9
|
5 | std::num::NonZeroU32(i) => {},
| ^^^^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `std::num::NonZeroU32 { 0 }`
|
::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>
**After:**
<details>
```Rust
➜ /rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc bug.rs
error[E0423]: cannot initialize a tuple struct which contains private fields
--> bug.rs:2:14
|
2 | let _x = std::num::NonZeroU32(12);
| ^^^^^^^^^^^^^^^^^^^^
|
note: constructor is not visible here due to private fields
--> /rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: cannot match against a tuple struct which contains private fields
--> bug.rs:5:9
|
5 | std::num::NonZeroU32(i) => {},
| ^^^^^^^^^^^^^^^^^^^^
|
note: constructor is not visible here due to private fields
--> bug.rs:5:30
|
5 | std::num::NonZeroU32(i) => {},
| ^ private field
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>
One question is if we should only collect the needed info for the cross-crate case after encountering an error instead of always doing it. Perf run perhaps to gauge the impact.
Suggest adding a type parameter for impls
Add a new suggestion upon encountering an unknown type in a `impl` that suggests adding a new type parameter. This diagnostic suggests to add a new type parameter even though it may be a const parameter, however after adding the parameter and running rustc again a follow up error steers the user to change the type parameter to a const parameter.
```rust
struct X<const C: ()>();
impl X<C> {}
```
suggests
```
error[E0412]: cannot find type `C` in this scope
--> bar.rs:2:8
|
1 | struct X<const C: ()>();
| ------------------------ similarly named struct `X` defined here
2 | impl X<C> {}
| ^
|
help: a struct with a similar name exists
|
2 | impl X<X> {}
| ^
help: you might be missing a type parameter
|
2 | impl<C> X<C> {}
| ^^^
```
After adding a type parameter the code now becomes
```rust
struct X<const C: ()>();
impl<C> X<C> {}
```
and the error now fully steers the user towards the correct code
```
error[E0747]: type provided when a constant was expected
--> bar.rs:2:11
|
2 | impl<C> X<C> {}
| ^
|
help: consider changing this type parameter to be a `const` generic
|
2 | impl<const C: ()> X<C> {}
| ^^^^^^^^^^^
```
r? `@estebank`
Somewhat related #84946
Handle more span edge cases in generics diagnostics
This should fix invalid suggestions that didn't account for empty bracket pairs (`<>`) or type bindings.
