Group "missing variable bind" spans in `or` matches and clarify wording
for the two possible cases: when a variable from the first pattern is
not in any of the subsequent patterns, and when a variable in any of the
other patterns is not in the first one.
Before:
```
error[E0408]: variable `a` from pattern #1 is not bound in pattern #2
--> file.rs:10:23
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^^^^ pattern doesn't bind `a`
error[E0408]: variable `b` from pattern #2 is not bound in pattern #1
--> file.rs:10:32
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^ pattern doesn't bind `b`
error[E0408]: variable `a` from pattern #1 is not bound in pattern #3
--> file.rs:10:37
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `a`
error[E0408]: variable `d` from pattern #1 is not bound in pattern #3
--> file.rs:10:37
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `d`
error[E0408]: variable `c` from pattern #3 is not bound in pattern #1
--> file.rs:10:43
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^ pattern doesn't bind `c`
error[E0408]: variable `d` from pattern #1 is not bound in pattern #4
--> file.rs:10:48
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `d`
error: aborting due to 6 previous errors
```
After:
```
error[E0408]: variable `a` is not bound in all patterns
--> file.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| - ^^^^^^^^^^^ ^^^^^^^^ - variable
t in all patterns
| | | |
| | | pattern doesn't bind `a`
| | pattern doesn't bind `a`
| variable not in all patterns
error[E0408]: variable `d` is not bound in all patterns
--> file.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| - - ^^^^^^^^ ^^^^^^^^ pattern
esn't bind `d`
| | | |
| | | pattern doesn't bind `d`
| | variable not in all patterns
| variable not in all patterns
error[E0408]: variable `b` is not bound in all patterns
--> file.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| ^^^^^^^^^^^ - ^^^^^^^^ ^^^^^^^^ pattern
esn't bind `b`
| | | |
| | | pattern doesn't bind `b`
| | variable not in all patterns
| pattern doesn't bind `b`
error[E0408]: variable `c` is not bound in all patterns
--> file.rs:20:48
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| ^^^^^^^^^^^ ^^^^^^^^^^^ - ^^^^^^^^ pattern
esn't bind `c`
| | | |
| | | variable not in all
tterns
| | pattern doesn't bind `c`
| pattern doesn't bind `c`
error: aborting due to 4 previous errors
```
* Have only one presentation for binding consistency errors
* Point to same binding in multiple patterns when possible
* Check inconsistent bindings in all arms
* Simplify wording of diagnostic message
* Sort emition and spans of binding errors for deterministic output
This commit searchs modules for macro suggestions.
It also removes imported macro_rules from macro_names,
and adds more corner case checks for which macros
should be suggested in specific contexts.
Don't suggest to use things which weren't found either
Fixes#38054
The best code I can come up with, suggestions are welcome.
Basically, removing ```. Did you mean to use `DoesntExist1`?``` in the code below, because it is useless.
```rust
error[E0432]: unresolved import `DoesntExist1`
--> src/lib.rs:1:5
|
1 | use DoesntExist1;
| ^^^^^^^^^^^^ no `DoesntExist1` in the root
error[E0432]: unresolved import `DoesntExist2`
--> src/lib.rs:2:5
|
2 | use DoesntExist2;
| ^^^^^^^^^^^^ no `DoesntExist2` in the root. Did you mean to use `DoesntExist1`?
```
Partially implement RFC 1647 (`Self` in impl headers)
The name resolution part is easy, but the typeck part contains an unexpected problem.
It turns out that `Self` type *depends* on bounds and `where` clauses, so we need to convert them first to determine what the `Self` type is! If bounds/`where` clauses can refer to `Self` then we have a cyclic dependency.
This is required to support impls like this:
```
// Found in libcollections
impl<I: IntoIterator> SpecExtend<I> for LinkedList<I::Item> { .... }
^^^^^ associated type `Item` is found using information from bounds
```
I'm not yet sure how to resolve this issue.
One possible solution (that feels hacky) is to make two passes over generics - first collect predicates ignoring everything involving `Self`, then determine `Self`, then collect predicates again without ignoring anything. (Some kind of lazy on-demand checking or something looks like a proper solution.)
This patch in its current state doesn't solve the problem with `Self` in bounds, so the only observable things it does is improving error messages and supporting `impl Trait<Self> for Type {}`.
There's also a question about feature gating. It's non-trivial to *detect* "newly resolved" `Self`s to feature gate them, but it's simple to *enable* the new resolution behavior when the feature gate is already specified. Alternatively this can be considered a bug fix and merged without a feature gate.
cc https://github.com/rust-lang/rust/issues/38864
r? @nikomatsakis
cc @eddyb
Whitespace ignoring diff https://github.com/rust-lang/rust/pull/38920/files?w=1
Use multiline Diagnostic for candidate in other module
```
error[E0574]: expected struct, variant or union type, found enum `Result`
--> $DIR/issue-16058.rs:19:9
|
19 | Result {
| ^^^^^^ not a struct, variant or union type
|
= help: possible better candidates are found in other modules, you can import them into scope:
`use std::fmt::Result;`
`use std::io::Result;`
`use std:🧵:Result;`
error: aborting due to previous error
```
* Add support for `#[proc_macro]`
* Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it
* Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`,
error on legacy import of proc macros via `#[macro_use]`
resolve: Do not use "resolve"/"resolution" in error messages
Use less jargon-y wording instead.
`cannot find <struct> <S> in <this scope>` and `cannot find <struct> <S> in <module a::b>` are used for base messages (this also harmonizes nicely with "you can import it into scope" suggestions) and `not found in <this scope>` and `not found in <a::b>` are used for short labels in fall-back case.
I tweaked some other diagnostics to avoid using "resolve" (see, e.g., `librustc_resolve/macros.rs`), but haven't touched messages for imports.
Closes https://github.com/rust-lang/rust/issues/38750
r? @nrc
resolve: clean up the semantics of `self` in an import list
Change `self` in an import list `use foo::bar::{self, ...};` to import `bar` only in the type namespace. Today, `bar` is imported in every namespace in which `foo::bar` is defined.
This is a [breaking-change], see https://github.com/rust-lang/rust/issues/38293#issue-194817974 for examples of code that would break.
Fixes#38293.
r? @nrc
Remove not(stage0) from deny(warnings)
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
i128 and u128 support
Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.
Rebased version of #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen#37900 due to github. There goes my premium position in the homu queue...
[plugin-breaking-change]
cc #35118 (tracking issue)
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.
In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).
This commit includes manual merge conflict resolution changes from a rebase by @est31.
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
Use `DefId`s instead of `NodeId`s for `pub(restricted)` visibilities
This is groundwork for hygiene 2.0, specifically privacy checking hygienic intercrate name resolutions.
r? @nrc
Allow legacy custom derive authors to disable warnings in downstream crates
This PR allows legacy custom derive authors to use a pre-deprecated method `registry.register_custom_derive()` instead of `registry.register_syntax_extension()` to avoid downstream deprecation warnings.
r? @nrc
annotate stricter lifetimes on LateLintPass methods to allow them to forward to a Visitor
this unblocks clippy (rustup blocked after #37918)
clippy has lots of lints that internally call an `intravisit::Visitor`, but the current lifetimes on `LateLintPass` methods conflicted with the required lifetimes (there was no connection between the HIR elements and the `TyCtxt`)
r? @Manishearth
For a given file
```rust
use std::*;
use std::{};
```
output the following warnings
```
warning: unused import: `use std::{};`, #[warn(unused_imports)] on by default
--> file.rs:2:1
|
2 | use std::{};
| ^^^^^^^^^^^^
warning: unused import: `std::*;`, #[warn(unused_imports)] on by default
--> file.rs:1:5
|
1 | use std::*;
| ^^^^^^^
```
Avoid loading needless proc-macro dependencies
Fixes#37958 when no proc-macros are exported; in particular, without `pub extern crate proc_macros;`, `#![feature(macro_reexport)]`, or `#![feature(use_extern_macros)]`.
I opened https://github.com/rust-lang/cargo/issues/3334 for exported proc macros.
r? @alexcrichton
This implements RFC 1624, tracking issue #37339.
- `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s, which store the
currently deduced type of that loop, the desired type, and a list of
break expressions currently seen. `loop` loops get a fresh type
variable as their initial type (this logic is stolen from that for
arrays). `while` loops get `()`.
- `break {expr}` looks up the broken loop, and unifies the type of
`expr` with the type of the loop.
- `break` with no expr unifies the loop's type with `()`.
- When building MIR, `loop` loops no longer construct a `()` value at
termination of the loop; rather, the `break` expression assigns the
result of the loop. `while` loops are unchanged.
- `break` respects contexts in which expressions may not end with braced
blocks. That is, `while break { break-value } { while-body }` is
illegal; this preserves backwards compatibility.
- The RFC did not make it clear, but I chose to make `break ()` inside
of a `while` loop illegal, just in case we wanted to do anything with
that design space in the future.
This is my first time dealing with this part of rustc so I'm sure
there's plenty of problems to pick on here ^_^
Clean up `ast::Attribute`, `ast::CrateConfig`, and string interning
This PR
- removes `ast::Attribute_` (changing `Attribute` from `Spanned<Attribute_>` to a struct),
- moves a `MetaItem`'s name from the `MetaItemKind` variants to a field of `MetaItem`,
- avoids needlessly wrapping `ast::MetaItem` with `P`,
- moves string interning into `syntax::symbol` (`ast::Name` is a reexport of `symbol::Symbol` for now),
- replaces `InternedString` with `Symbol` in the AST, HIR, and various other places, and
- refactors `ast::CrateConfig` from a `Vec` to a `HashSet`.
r? @eddyb
Group unused import warnings per import list
Given a file
``` rust
use std::collections::{BinaryHeap, BTreeMap, BTreeSet};
fn main() {}
```
Show a single warning, instead of three for each unused import:
``` nocode
warning: unused imports, #[warn(unused_imports)] on by default
--> file2.rs:1:24
|
1 | use std::collections::{BinaryHeap, BTreeMap, BTreeSet};
| ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^
```
Include support for lints pointing at `MultilineSpan`s, instead of just
`Span`s.
Fixes#16132.
Show one error for duplicated type definitions
For the following code:
``` rustc
struct Bar;
struct Bar;
fn main () {
}
```
show
``` nocode
error[E0428]: a type named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error: aborting due to previous error
```
instead of
``` nocode
error[E0428]: a type named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error[E0428]: a value named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error: aborting due to 2 previous errors
```
Fixes#35767.
Fix regression involving custom derives on items with `$crate`
The regression was introduced in #37213.
I believe we cannot make the improvements from #37213 work with the current custom derive setup (c.f. https://github.com/rust-lang/rust/issues/37637#issuecomment-258959145) -- we'll have to wait for `TokenStream`'s API to improve.
Fixes#37637.
r? @nrc
[6/n] rustc: transition HIR function bodies from Block to Expr.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37408) | [next](https://github.com/rust-lang/rust/pull/37676)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
The main change here is that functions and closures both use `Expr` instead of `Block` for their bodies.
For closures this actually allows a honest representation of brace-less closure bodies, e.g. `|x| x + 1` is now distinguishable from `|x| { x + 1 }`, therefore this PR is `[syntax-breaking]` (cc @Manishearth).
Using `Expr` allows more logic to be shared between constant bodies and function bodies, with some small such changes already part of this PR, and eventually easing #35078 and per-body type tables.
Incidentally, there used to be some corners cut here and there and as such I had to (re)write divergence tracking for type-checking so that it is capable of understanding basic structured control-flow:
``` rust
fn a(x: bool) -> i32 {
// match also works (as long as all arms diverge)
if x { panic!("true") } else { return 1; }
0 // "unreachable expression" after this PR
}
```
And since liveness' "not all control paths return a value" moved to type-checking we can have nice things:
``` rust
// before & after:
fn b() -> i32 { 0; } // help: consider removing this semicolon
// only after this PR
fn c() -> i32 { { 0; } } // help: consider removing this semicolon
fn d() { let x: i32 = { 0; }; } // help: consider removing this semicolon
fn e() { f({ 0; }); } // help: consider removing this semicolon
```
For the following code:
```rustc
struct Bar;
struct Bar;
fn main () {
}
```
show
```nocode
error[E0428]: a type named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error: aborting due to previous error
```
instead of
```nocode
error[E0428]: a type named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error[E0428]: a value named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error: aborting due to 2 previous errors
```
Point to type argument span when used as trait
Given the following code:
``` rust
struct Foo<T: Clone>(T);
use std::ops::Add;
impl<T: Clone, Add> Add for Foo<T> {
type Output = usize;
fn add(self, rhs: Self) -> Self::Output {
unimplemented!();
}
}
```
present the following output:
``` nocode
error[E0404]: `Add` is not a trait
--> file3.rs:5:21
|
5 | impl<T: Clone, Add> Add for Okok<T> {
| --- ^^^ expected trait, found type parameter
| |
| type parameter defined here
```
Fixes#35987.
Replace FNV with a faster hash function.
Hash table lookups are very hot in rustc profiles and the time taken within `FnvHash` itself is a big part of that. Although FNV is a simple hash, it processes its input one byte at a time. In contrast, Firefox has a homespun hash function that is also simple but works on multiple bytes at a time. So I tried it out and the results are compelling:
```
futures-rs-test 4.326s vs 4.212s --> 1.027x faster (variance: 1.001x, 1.007x)
helloworld 0.233s vs 0.232s --> 1.004x faster (variance: 1.037x, 1.016x)
html5ever-2016- 5.397s vs 5.210s --> 1.036x faster (variance: 1.009x, 1.006x)
hyper.0.5.0 5.018s vs 4.905s --> 1.023x faster (variance: 1.007x, 1.006x)
inflate-0.1.0 4.889s vs 4.872s --> 1.004x faster (variance: 1.012x, 1.007x)
issue-32062-equ 0.347s vs 0.335s --> 1.035x faster (variance: 1.033x, 1.019x)
issue-32278-big 1.717s vs 1.622s --> 1.059x faster (variance: 1.027x, 1.028x)
jld-day15-parse 1.537s vs 1.459s --> 1.054x faster (variance: 1.005x, 1.003x)
piston-image-0. 11.863s vs 11.482s --> 1.033x faster (variance: 1.060x, 1.002x)
regex.0.1.30 2.517s vs 2.453s --> 1.026x faster (variance: 1.011x, 1.013x)
rust-encoding-0 2.080s vs 2.047s --> 1.016x faster (variance: 1.005x, 1.005x)
syntex-0.42.2 32.268s vs 31.275s --> 1.032x faster (variance: 1.014x, 1.022x)
syntex-0.42.2-i 17.629s vs 16.559s --> 1.065x faster (variance: 1.013x, 1.021x)
```
(That's a stage1 compiler doing debug builds. Results for a stage2 compiler are similar.)
The attached commit is not in a state suitable for landing because I changed the implementation of FnvHasher without changing its name (because that would have required touching many lines in the compiler). Nonetheless, it is a good place to start discussions.
Profiles show very clearly that this new hash function is a lot faster to compute than FNV. The quality of the new hash function is less clear -- it seems to do better in some cases and worse in others (judging by the number of instructions executed in `Hash{Map,Set}::get`).
CC @brson, @arthurprs
Given a file
```rust
use std::collections::{BinaryHeap, BTreeMap, BTreeSet};
fn main() {}
```
Show a single warning, instead of three for each unused import:
```nocode
warning: unused imports, #[warn(unused_imports)] on by default
--> foo.rs:1:24
|
1 | use std::collections::{BinaryHeap, BTreeMap, BTreeSet};
| ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^
```
Include support for lints pointing at `MultilineSpan`s, instead of just
`Span`s.
Given the following code:
```rust
struct Foo<T: Clone>(T);
use std::ops::Add;
impl<T: Clone, Add> Add for Foo<T> {
type Output = usize;
fn add(self, rhs: Self) -> Self::Output {
unimplemented!();
}
}
```
present the following output:
```nocode
error[E0404]: `Add` is not a trait
--> file3.rs:5:21
|
5 | impl<T: Clone, Add> Add for Okok<T> {
| --- ^^^ expected trait, found type parameter
| |
| type parameter defined here
```
Stabilize `..` in tuple (struct) patterns
I'd like to nominate `..` in tuple and tuple struct patterns for stabilization.
This feature is a relatively small extension to existing stable functionality and doesn't have known blockers.
The feature first appeared in Rust 1.10 6 months ago.
An example of use: https://github.com/rust-lang/rust/pull/36203
Closes https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis
macros: improve shadowing checks
This PR improves macro-expanded shadowing checks to work with out-of-(pre)order expansion.
Out-of-order expansion became possible in #37084, so this technically a [breaking-change] for nightly.
The regression test from this PR is an example of code that would break.
r? @nrc
Add E0532 error explanation
This resolves one of the error list in https://github.com/rust-lang/rust/issues/35347 - just because I stumbled over it today.
I assumed the error code should be removed from `register_diagnostics!` because it's now defined above.
Since that is my first code contribution, please check that all is in order. It would be helpful to know how to run the test for the `compile_fail,E0532` part. I did `make check-stage1-cfail NO_REBUILD=1` but that doesn't test the inlined example.
r? @GuillaumeGomez
Add semicolon to "Maybe a missing `extern crate foo`" message
I had it a couple of times that I was missing the "extern crate" line
after I introduced a new dependency. So I copied the text from the
message and inserted it into the beginning of my code, only to find the
compiler complaining that I was missing the semicolon. (I forgot to add
it after the text that I had pasted.)
There's a similar message which does include the semicolon, namely
"help: you can import it into scope: `use foo::Bar;`". I think the two
messages should be consistent, so this change adds it for "extern
crate".
Diagnostics for struct path resolution errors in resolve and typeck are unified.
Self type is treated as a type alias in few places (not reachable yet).
Unsafe cell is seen in constants even through type aliases.
All checks for struct paths in typeck work on type level.
I had it a couple of times that I was missing the "extern crate" line
after I introduced a new dependency. So I copied the text from the
message and inserted it into the beginning of my code, only to find the
compiler complaining that I was missing the semicolon. (I forgot to add
it after the text that I had pasted.)
There's a similar message which does include the semicolon, namely
"help: you can import it into scope: `use foo::Bar;`". I think the two
messages should be consistent, so this change adds it for "extern
crate".
Add identifier to unused import warnings
Fix#37376.
For some reason, though, I'm getting warnings with messages like "76:9: 76:16: unused import: `self::g`" instead of "unused import: `self::g`". @pnkfelix Any ideas what might be causing this?
