Minimize single span suggestions into a label
changes
```
14 | println!("☃{}", tup[0]);
| ^^^^^^
|
help: to access tuple elements, use tuple indexing syntax as shown
| println!("☃{}", tup.0);
```
into
```
14 | println!("☃{}", tup[0]);
| ^^^^^^ to access tuple elements, use `tup.0`
```
Also makes suggestions explicit in the backend in preparation of adding multiple suggestions to a single diagnostic. Currently that's already possible, but results in a full help message + modified code snippet per suggestion, and has no rate limit (might show 100+ suggestions).
`try_index_step` does not resolve type variables by itself and would
fail otherwise. Also harden the failure path in `confirm` to cause less
confusing errors.
When a span starts on a line with nothing but whitespace to the left,
and there are no other annotations in that line, simplify the visual
representation of the span.
Go from:
```rust
error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | struct A {
| _^ starting here...
2 | | a: A,
3 | | }
| |_^ ...ending here: recursive type has infinite size
|
```
To:
```rust
error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | / struct A {
2 | | a: A,
3 | | }
| |_^ recursive type has infinite size
```
Remove `starting here...`/`...ending here` labels from all multiline
diagnostics.
Highlight and simplify mismatched types
Shorten mismatched types errors by replacing subtypes that are not
different with `_`, and highlighting only the subtypes that are
different.
Given a file
```rust
struct X<T1, T2> {
x: T1,
y: T2,
}
fn foo() -> X<X<String, String>, String> {
X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
}
fn bar() -> Option<String> {
"".to_string()
}
```
provide the following output
```rust
error[E0308]: mismatched types
--> file.rs:6:5
|
6 | X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `std::string::String`, found {integer}
|
= note: expected type `X<X<_, std::string::String>, _>`
^^^^^^^^^^^^^^^^^^^ // < highlighted
found type `X<X<_, {integer}>, _>`
^^^^^^^^^ // < highlighted
error[E0308]: mismatched types
--> file.rs:6:5
|
10 | "".to_string()
| ^^^^^^^^^^^^^^ expected struct `std::option::Option`, found `std::string::String`
|
= note: expected type `Option<std::string::String>`
^^^^^^^ ^ // < highlighted
found type `std::string::String`
```
Fix#21025. Re: #40186. Follow up to #39906.
I'm looking to change how this output is accomplished so that it doesn't create list of strings to pass around, but rather add an elided `Ty` placeholder, and use the same string formatting for normal types. I'll be doing that soonish.
r? @nikomatsakis
Fix multiple labels when some don't have message
The diagnostic emitter now accounts for labels with no text message, presenting the underline on its own, without drawing the line for the non existing message below it. Go from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| | |
| | `b` is a good letter
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| |
| `b` is a good letter
```
from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
| `a` is a good letter
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^ `a` is a good letter
```
and from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
```
r? @nikomatsakis
cc @jonathandturner, @GuillaumeGomez, @nrc
The diagnostic emitter now accounts for labels with no text message,
presenting the underline on its own, without drawing the line for the
non existing message below it. Go from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| | |
| | `b` is a good letter
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| |
| `b` is a good letter
```
and from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
| `a` is a good letter
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^ `a` is a good letter
```
Teach diagnostics to correct margin of multiline messages
Make the suggestion list have a correct padding:
```
error[E0308]: mismatched types
--> file.rs:3:20
|
3 | let x: usize = "";
| ^^ expected usize, found reference
|
= note: expected type `usize`
= note: found type `&'static str`
= help: here are some functions which might fulfill your needs:
- .len()
- .foo()
- .bar()
```
Make any diagnostic line to have the correct margin to align with the
first line:
```
error: message
--> file.rs:3:20
|
3 | <CODE>
| ^^^^
|
= note: this is a multiline
note with a correct
margin
= note: this is a single line note
= help: here are some functions which might fulfill your needs:
- .len()
- .foo()
- .bar()
= suggestion: this is a multiline
suggestion with a
correct margin
```
Make the suggestion list have a correct padding:
```
error[E0308]: mismatched types
--> file.rs:3:20
|
3 | let x: usize = "";
| ^^ expected usize, found reference
|
= note: expected type `usize`
= note: found type `&'static str`
= help: here are some functions which might fulfill your needs:
- .len()
- .foo()
- .bar()
```
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.
When dealing with multiline spans that span few lines, show the complete
span instead of restricting to the first character of the first line.
For example, instead of:
```
% ./rustc foo.rs
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
--> foo.rs:13:9
|
13 | foo(1 + bar(x,
| ^ trait `{integer}: std::ops::Add<()>` not satisfied
|
```
show
```
% ./rustc foo.rs
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
--> foo.rs:13:9
|
13 | foo(1 + bar(x,
| ________^ starting here...
14 | | y),
| |_____________^ ...ending here: trait `{integer}: std::ops::Add<()>` not satisfied
|
```
This commit is a rewrite of the user-facing interface to the rustbuild build
system. The intention here is to make it much easier to compile/test the project
without having to remember weird rule names and such. An overall view of the new
interface is:
# build everything
./x.py build
# document everyting
./x.py doc
# test everything
./x.py test
# test libstd
./x.py test src/libstd
# build libcore stage0
./x.py build src/libcore --stage 0
# run stage1 run-pass tests
./x.py test src/test/run-pass --stage 1
The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py`
script. This `x` was chosen to be both short and easily tab-completable (no
collisions in that namespace!). The build system now accepts a "subcommand" of
what to do next, the main ones being build/doc/test.
Each subcommand then receives an optional list of arguments. These arguments are
paths in the source repo of what to work with. That is, if you want to test a
directory, you just pass that directory as an argument.
The purpose of this rewrite is to do away with all of the arcane renames like
"rpass" is the "run-pass" suite, "cfail" is the "compile-fail" suite, etc. By
simply working with directories and files it's much more intuitive of how to run
a test (just pass it as an argument).
The rustbuild step/dependency management was also rewritten along the way to
make this easy to work with and define, but that's largely just a refactoring of
what was there before.
The *intention* is that this support is extended for arbitrary files (e.g.
`src/test/run-pass/my-test-case.rs`), but that isn't quite implemented just yet.
Instead directories work for now but we can follow up with stricter path
filtering logic to plumb through all the arguments.
Fix wording for out-of-crate macro error
This fixes the wording of the note for out-of-crate macro errors to fix https://github.com/rust-lang/rust/issues/36469
The previous wording came from older logic in the PR that was replaced without updating the note.
Be more specific when type parameter shadows primitive type
When a type parameter shadows a primitive type, the error message
was non obvious. For example, given the file `file.rs`:
```rust
trait Parser<T> {
fn parse(text: &str) -> Option<T>;
}
impl<bool> Parser<bool> for bool {
fn parse(text: &str) -> Option<bool> {
Some(true)
}
}
fn main() {
println!("{}", bool::parse("ok").unwrap_or(false));
}
```
The output was:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool a
|
= note: expected type `bool`
= note: found type `bool`
error: aborting due to previous error
```
We now show extra information about the type:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool a
|
= note: expected type `bool` (type parameter)
= note: found type `bool` (bool)
error: aborting due to previous error
```
Fixes#35030
When a type parameter shadows a primitive type, the error message
was non obvious. For example, given the file `file.rs`:
```rust
trait Parser<T> {
fn parse(text: &str) -> Option<T>;
}
impl<bool> Parser<bool> for bool {
fn parse(text: &str) -> Option<bool> {
Some(true)
}
}
fn main() {
println!("{}", bool::parse("ok").unwrap_or(false));
}
```
The output was:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool
|
= note: expected type `bool`
= note: found type `bool`
error: aborting due to previous error
```
We now show extra information about the type:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool
|
= note: expected type `bool` (type parameter)
= note: found type `bool` (bool)
error: aborting due to previous error
```
Fixes#35030
