| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Move ICH to rustc_query_system
Based on https://github.com/rust-lang/rust/pull/89183
The StableHashingContext does not need to be in rustc_middle.
This PR moves it to rustc_query_system. This will avoid a dependency between rustc_ast_lowering and rustc_middle in https://github.com/rust-lang/rust/pull/89124.
|
|
|
|
|
|
It makes all block modules identical during comparison
|
|
It was previously cached for modules loaded from `fn get_module`, but not for modules loaded from `fn build_reduced_graph_for_external_crate_res`.
This also makes all foreign modules use their real parent, span and expansion instead of possibly a parent/span/expansion of their reexport.
An ICE happening on attempt to decode expansions for foreign enums and traits is avoided.
Also local enums and traits are now added to the module map.
|
|
Rollup of 7 pull requests
Successful merges:
- #88838 (Do not suggest importing inaccessible items)
- #89251 (Detect when negative literal indices are used and suggest appropriate code)
- #89321 (Rebase resume argument projections during state transform)
- #89327 (Pick one possible lifetime in case there are multiple choices)
- #89344 (Cleanup lower_generics_mut and make span be the bound itself)
- #89397 (Update `llvm` submodule to fix function name mangling on x86 Windows)
- #89412 (Add regression test for issues #88969 and #89119 )
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Cleanup lower_generics_mut and make span be the bound itself
Closes #86298 (supersedes those changes)
r? `@cjgillot` since you reviewed the other PR
(Used wrong branch for #89338)
|
|
Do not suggest importing inaccessible items
Fixes #88472. For this example:
```rust
mod a {
struct Foo;
}
mod b {
type Bar = Foo;
}
```
rustc currently emits:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
help: consider importing this struct
|
6 | use a::Foo;
|
```
this is incorrect, as applying this suggestion leads to
```
error[E0603]: struct `Foo` is private
--> test.rs:6:12
|
6 | use a::Foo;
| ^^^ private struct
|
note: the struct `Foo` is defined here
--> test.rs:2:5
|
2 | struct Foo;
| ^^^^^^^^^^^
```
With my changes, I get:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
= note: this struct exists but is inaccessible:
a::Foo
```
As for the wildcard mentioned in #88472, I would argue that the warning is actually correct, since the import _is_ unused. I think the real issue is the wrong suggestion, which I have fixed here.
|
|
In-line:remove_visible_path_from_allowed_deprecated_lint, r=jyn514
Remove visible path calculation from allowed deprecation lint
|
|
r=estebank
Suggest similarly named associated items in trait impls
Fix #85942
Previously, the compiler didn't suggest similarly named associated items unlike we do in many situations. This patch adds such diagnostics for associated functions, types, and constants.
|
|
|
|
|
|
Previously, the compiler didn't suggest similarly named associated items
unlike we do in many situations. This patch adds such diagnostics for
associated functions, types and constants.
|
|
|
|
|
|
|
|
|
|
Change the order of imports suggestions
closes #83564
|
|
Make `#[derive(A, B, ...)]` cfg-eval its input only for `A, B, ...` and stabilize `feature(macro_attributes_in_derive_output)`
Stabilization report: https://github.com/rust-lang/rust/pull/87220#issuecomment-881923657
Closes #81119
r? `@Aaron1011`
|
|
|
|
|
|
The `Option<Module>` version is supported for the case where we don't know whether the `DefId` refers to a module or not.
Non-local traits and enums are also correctly found now.
|
|
|
|
|
|
Construction of all modules is now centralized and performed by `fn new_module`.
|
|
|
|
|
|
Cleanup: Remove needless reference in ParentHirIterator
It forces an intermediate binding of `Map` which is a Copy type.
|
|
Check for shadowing issues involving block labels
|
|
|
|
Skip single use lifetime lint for generated opaque types
Fix: #77175
The opaque type generated by the desugaring process of an async function uses the lifetimes defined by the originating function. The DefId for the lifetimes in the opaque type are different from the ones in the originating async function - as they should be, as far as I understand, and could therefore be considered a single use lifetimes, 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.
More info in the comments on the original issue: 1 and 2
|
|
|
|
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
|
|
rustc: Remove local variable IDs from `Export`s
Local variables can never be exported.
|
|
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.
|
|
|
|
Local variables can never be exported.
|
|
|
|
|
|
|
|
|
|
This eliminates untracked global state from `Session`.
|
|
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`.
|
|
Move global analyses from lowering to resolution
Split off https://github.com/rust-lang/rust/pull/87234
r? `@petrochenkov`
|
|
Address part of #34255.
Potential improvement: silence the other knock down errors in
`issue-34255-1.rs`.
|
|
r=jyn514,GuillaumeGomez
some low hanging clippy::perf fixes
|
|
|
|
|
