| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
CrateStore access in tcx.
|
|
rustc: Remove HirId from queries
This'll allow us to reconstruct query parameters purely from the `DepNode`
they're associated with.
Closes #44414
|
|
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
|
|
|
|
expansions
|
|
|
|
|
|
|
|
|
|
Fixes #41701.
|
|
rustc: Remove some dead code
Extracted from https://github.com/rust-lang/rust/pull/43192
r? @eddyb
|
|
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
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`
```
|
|
This commit bumps the master branch's version to 1.21.0 and also updates the
bootstrap compiler from the freshly minted beta release.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
```
|
|
Add E0603 error code
Part of #42229.
cc @Susurrus
|
|
Extend the unused macro lint to macros 2.0
Extends the unused macro lint (added in PR #41907) to macros 2.0 (added in PR #40847).
r? @jseyfried
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add lint for unused macros
Addresses parts of #34938, to add a lint for unused macros.
We now output warnings by default when we encounter a macro that we didn't use for expansion.
Issues to be resolved before this PR is ready for merge:
- [x] fix the NodeId issue described above
- [x] remove all unused macros from rustc and the libraries or set `#[allow(unused_macros)]` next to them if they should be kept for some reason. This is needed for successful boostrap and bors to accept the PR. -> #41934
- [x] ~~implement the full extent of #34938, that means the macro match arm checking as well.~~ *let's not do this for now*
|
|
|
|
|
|
|
|
Rollup of 15 pull requests
- Successful merges: #41820, #41860, #41876, #41896, #41912, #41916, #41918, #41921, #41923, #41934, #41935, #41940, #41942, #41943, #41951
- Failed merges:
|
