rustc: Rearchitect lints to be emitted more eagerly
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
Closes https://github.com/rust-lang/rust/issues/42511
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
resolve: Try to fix instability in import suggestions
cc https://github.com/rust-lang/rust/pull/42033
`lookup_import_candidates` walks module graph in DFS order and skips modules that were already visited (which is correct because there can be cycles).
However it means that if we visited `std::prelude::v1::Result::Ok` first, we will never visit `std::result::Result::Ok` because `Result` will be skipped as already visited (note: enums are also modules here), and otherwise, if we visited `std::result::Result::Ok` first, we will never get to `std::prelude::v1::Result::Ok`.
What child module of `std` (`prelude` or `result`) we will visit first, depends on randomized hashing, so we have instability in diagnostics.
With this patch modules' children are visited in stable order in `lookup_import_candidates`, this should fix the issue, but let's see what Travis will say.
r? @oli-obk
This PR kicks off the implementation of the [default binding modes RFC][1] by
introducing the `pat_binding_modes` typeck table mentioned in the [mentoring
instructions][2].
`pat_binding_modes` is populated in `librustc_typeck/check/_match.rs` and
used wherever the HIR would be scraped prior to this PR. Unfortunately, one
blemish, namely a two callers to `contains_explicit_ref_binding`, remains.
This will likely have to be removed when the second part of [1], the
`pat_adjustments` table, is tackled. Appropriate comments have been added.
See #42640.
[1]: https://github.com/rust-lang/rfcs/pull/2005
[2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089
Point at path segment on module not found
Point at the correct path segment on a import statement where a module
doesn't exist.
New output:
```rust
error[E0432]: unresolved import `std::bar`
--> <anon>:1:10
|
1 | use std::bar::{foo1, foo2};
| ^^^ Could not find `bar` in `std`
```
instead of:
```rust
error[E0432]: unresolved import `std::bar::foo1`
--> <anon>:1:16
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
error[E0432]: unresolved import `std::bar::foo2`
--> <anon>:1:22
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
```
Fix#43040.
Point at the correct path segment on a import statement where a module
doesn't exist.
New output:
```rust
error[E0432]: unresolved import `std::bar`
--> <anon>:1:10
|
1 | use std::bar::{foo1, foo2};
| ^^^ Could not find `bar` in `std`
```
instead of:
```rust
error[E0432]: unresolved import `std::bar::foo1`
--> <anon>:1:16
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
error[E0432]: unresolved import `std::bar::foo2`
--> <anon>:1:22
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
```
Point at `:` when using it instead of `;`
When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
Fix#42057, #41928.
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
Clearer Error Message for Duplicate Definition
Clearer use of the error message and span labels to communicate duplication definitions/imports.
fixes#42061
Clearer use of the error message and span labels to communicate
duplicaiton defitions/imports.
New error format:
```
error[E0428]: the name `Foo` is defined twice
--> example.rs:2:1
|
1 | trait Foo { }
| ------------- previous definition of the trait `Foo` here
2 | struct Foo { }
| ^^^^^^^^^^^^^^ `Foo` redefined here
= note: `Foo` must be defined only once in the type namespace of this module
error: aborting due to previous error
```
Fix translation of external spans
Previously, I noticed that spans from external crates don't generate any output. This limitation is problematic if analysis is performed on one or more external crates, as is the case with [rust-semverver](https://github.com/ibabushkin/rust-semverver). This change should address this behaviour, with the potential drawback that a minor performance hit is to be expected, as spans from potentially large crates have to be translated now.
