If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
Point at formatting descriptor string when it is invalid
When a formatting string contains an invalid descriptor, point at it
instead of the argument:
```
error: unknown format trait `foo`
--> $DIR/ifmt-bad-arg.rs:86:17
|
LL | println!("{:foo}", 1);
| ^^^
|
= note: the only appropriate formatting traits are:
- ``, which uses the `Display` trait
- `?`, which uses the `Debug` trait
- `e`, which uses the `LowerExp` trait
- `E`, which uses the `UpperExp` trait
- `o`, which uses the `Octal` trait
- `p`, which uses the `Pointer` trait
- `b`, which uses the `Binary` trait
- `x`, which uses the `LowerHex` trait
- `X`, which uses the `UpperHex` trait
```
When a formatting string contains an invalid descriptor, point at it
instead of the argument:
```
error: unknown format trait `foo`
--> $DIR/ifmt-bad-arg.rs:86:17
|
LL | println!("{:foo}", 1);
| ^^^
|
= note: the only appropriate formatting traits are:
- ``, which uses the `Display` trait
- `?`, which uses the `Debug` trait
- `e`, which uses the `LowerExp` trait
- `E`, which uses the `UpperExp` trait
- `o`, which uses the `Octal` trait
- `p`, which uses the `Pointer` trait
- `b`, which uses the `Binary` trait
- `x`, which uses the `LowerHex` trait
- `X`, which uses the `UpperHex` trait
```
Increase spacing for suggestions in diagnostics
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
r? @Centril
Add secondary span labels with no text to make it clear when there's a
mismatch bewteen the positional arguments in a format string and the
arguments to the macro. This shouldn't affect experienced users, but it
should make it easier for newcomers to more clearly understand how
`format!()` and `println!()` are supposed to be used.
```
error: 2 positional arguments in format string, but there is 1 argument
--> file8.rs:2:14
|
2 | format!("{} {}", 1);
| ^^ ^^ -
```
instead of
```
error: 2 positional arguments in format string, but there is 1 argument
--> file8.rs:2:14
|
2 | format!("{} {}", 1);
| ^^ ^^
```
When positional width and precision formatting flags are present in a
formatting string that has an argument count mismatch, provide extra
information pointing at them making it easiser to understand where the
problem may lay:
```
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:78:15
|
LL | println!("{} {:.*} {}", 1, 3.2, 4);
| ^^ ^^--^ ^^ --- this parameter corresponds to the precision flag
| |
| this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:81:15
|
LL | println!("{} {:07$.*} {}", 1, 3.2, 4);
| ^^ ^^-----^ ^^ --- this parameter corresponds to the precision flag
| | |
| | this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 3 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:84:15
|
LL | println!("{} {:07$} {}", 1, 3.2, 4);
| ^^ ^^---^ ^^
| |
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
```
Specific error for positional args after named args in `format!()`
When writing positional arguments after named arguments in the
`format!()` and `println!()` macros, provide a targeted diagnostic.
Follow up to https://github.com/rust-lang/rust/pull/57522/files#r247278885
Point at coercion reason for `if` expressions without else clause if caused by return type
```
error[E0317]: if may be missing an else clause
--> $DIR/if-without-else-as-fn-expr.rs:2:5
|
LL | fn foo(bar: usize) -> usize {
| ----- found `usize` because of this return type
LL | / if bar % 5 == 0 {
LL | | return 3;
LL | | }
| |_____^ expected (), found usize
|
= note: expected type `()`
found type `usize`
= note: `if` expressions without `else` must evaluate to `()`
```
Fix#25228.
```
error[E0317]: if may be missing an else clause
--> $DIR/if-without-else-as-fn-expr.rs:2:5
|
LL | fn foo(bar: usize) -> usize {
| ----- found `usize` because of this return type
LL | / if bar % 5 == 0 {
LL | | return 3;
LL | | }
| |_____^ expected (), found usize
|
= note: expected type `()`
found type `usize`
= note: `if` expressions without `else` must evaluate to `()`
```
- Point at the body expression of the match arm with the type error.
- Point at the prior match arms explicitely stating the evaluated type.
- Point at the entire match expr in a secondary span, instead of primary.
- For type errors in the first match arm, the cause is outside of the
match, treat as implicit block error to give a more appropriate error.
