doc-test: In Markdown tests, Use all of `<h1>` to `<h6>` as the test name
This mainly simplifies debugging error index tests, as the error codes are `<h2>`s in the huge document containing all codes.
don't suggest placing `use` statements into expanded code
r? @nrc
fixes#44210
```rust
#[derive(Debug)]
struct Foo;
type X = Path;
```
will try to place `use std::path::Path;` between `#[derive(Debug)]` and `struct Foo;`
I am not sure how to obtain a span before the first attribute, because derive attributes are removed during expansion.
It would be trivial to detect this case and place the `use` after the item, but that would be somewhat weird I think.
This'll allow us to reconstruct query parameters purely from the `DepNode`
they're associated with. Some queries could move straight to `HirId` but others
that don't always have a correspondance between `HirId` and `DefId` moved to
two-level maps where the query operates over a `DefIndex`, returning a map,
which is then keyed off `ItemLocalId`.
Closes#44414
Previously a `Symbol` was stored there, but this ended up causing hash
collisions in situations that otherwise shouldn't have a hash collision. Only
the symbol's string value was hashed, but it was possible for distinct symbols
to have the same string value, fooling various calcuations into thinking that
these paths *didn't* need disambiguating data when in fact they did!
By storing `InternedString` instead we're hopefully triggering all the exising
logic to disambiguate paths with same-name `Symbol` but actually distinct
locations.
These are only called pre-TyCtxt (e.g. lowering/resolve), so make it explicit in
the name that they're untracked and therefore unsuitable to called elsewhere.
The main use of `CrateStore` *before* the `TyCtxt` is created is during
resolution, but we want to be sure that any methods used before resolution are
not used after the `TyCtxt` is created. This commit starts moving the methods
used by resolve to all be named `{name}_untracked` where the rest of the
compiler uses just `{name}` as a query.
During this transition a number of new queries were added to account for
post-resolve usage of these methods.
rustc: Fix proc_macro expansions on trait methods
This commit fixes procedural macro attributes being attached to trait methods,
ensuring that they get resolved and expanded as other procedural macro
attributes. The bug here was that `current_module` on the resolver was
accidentally set to be a trait when it's otherwise only ever expecting a
`mod`/block module. The actual fix here came from @jseyfried, I'm just helping
to land it in the compiler!
Closes#42493
This commit fixes procedural macro attributes being attached to trait methods,
ensuring that they get resolved and expanded as other procedural macro
attributes. The bug here was that `current_module` on the resolver was
accidentally set to be a trait when it's otherwise only ever expecting a
`mod`/block module. The actual fix here came from @jseyfried, I'm just helping
to land it in the compiler!
Closes#42493
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.
