| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Previously, it only checked whether there was _a_ literal at the span of
the first argument, not whether the literal actually matched up. This
caused issues when a proc macro was generating a different literal with
the same span.
This requires an annoying special case for literals ending in `\n`
because otherwise `println` wouldn't give detailed diagnostics anymore
which would be bad.
|
|
Fix incorrect span when using byte-escaped rbrace
Fix #103826, a format args span issue introduced in #102214.
The current solution for tracking skipped characters made it so that certain situations were ambiguous enough that the original span couldn't be worked out later. This PR improves on the original solution by keeping track of groups of skipped characters using a map, and fixes the previous bug. See an example of this ambiguity in the [previous PR's discussion](https://github.com/rust-lang/rust/pull/102214#issuecomment-1258711015).
|
|
available
|
|
Fix #103826.
|
|
remove `find_skips`
remove unnecessary variables
|
|
|
|
|
|
Fix span of byte-escaped left format args brace
Fix #102057 (see issue for example).
Previously, the use of escaped left braces (`\x7B`) in format args resulted in an incorrectly offset span. This patch fixes that by considering any escaped characters within the string instead of using a constant offset.
|
|
Fix #102057.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes.
The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other.
We then modify that algorithm to detect 4 cases:
- A function input is missing
- An extra argument was provided
- The type of an argument is straight up invalid
- Two arguments have been swapped
- A subset of the arguments have been shuffled
(We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.)
It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site.
The basic sketch of the algorithm is as follows:
- Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input.
- If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type".
- Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument.
- Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input
- Swapped / Permuted arguments are identified with a cycle detection algorithm.
As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again.
Note that there's a lot of extra complexity:
- We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix.
- Closure arguments are wrapped in a tuple and need to be unwrapped
- We need to resolve closure types after the rest, to allow the most specific type constraints
- We need to handle imported C functions that might be variadic in their inputs.
I tried to document a lot of this in comments in the code and keep the naming clear.
|
|
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:
```
error[E0277]: the trait bound `f32: Foo` is not satisfied
--> $DIR/impl_wf.rs:22:6
|
LL | impl Baz<f32> for f32 { }
| ^^^^^^^^ the trait `Foo` is not implemented for `f32`
|
= help: the following other types implement trait `Foo`:
Option<T>
i32
str
note: required by a bound in `Baz`
--> $DIR/impl_wf.rs:18:31
|
LL | trait Baz<U: ?Sized> where U: Foo { }
| ^^^ required by this bound in `Baz`
```
Mention implementers of traits in `ImplObligation`s.
Do not mention other `impl`s for closures, ranges and `?`.
|
|
Stabilize `#[cfg(panic = "...")]`
[Stabilization PR](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr) for #77443
|
|
It should only include the identifier, or misspelling suggestions will be wrong.
|
|
Rebase commit
|
|
Don't allow {} to refer to implicit captures in format_args.
Fixes #93378
|
|
Accommodate yield points in the format_args expansion
Fixes #93274.
For the case `println!("{} {:?}", "", async {}.await)` in the issue, the expansion before:
```rust
::std::io::_print(
::core::fmt::Arguments::new_v1(
&["", " ", "\n"],
&[
::core::fmt::ArgumentV1::new(&"", ::core::fmt::Display::fmt),
::core::fmt::ArgumentV1::new(&async {}.await, ::core::fmt::Debug::fmt),
],
),
);
```
After:
```rust
::std::io::_print(
::core::fmt::Arguments::new_v1(
&["", " ", "\n"],
&match (&"", &async {}.await) {
_args => [
::core::fmt::ArgumentV1::new(_args.0, ::core::fmt::Display::fmt),
::core::fmt::ArgumentV1::new(_args.1, ::core::fmt::Debug::fmt),
],
},
),
);
```
|
|
|
|
Currently fails with:
error: future cannot be sent between threads safely
--> $DIR/src/test/ui/fmt/format-with-yield-point.rs:21:17
|
LL | assert_send(with_await());
| ^^^^^^^^^^^^ future returned by `with_await` is not `Send`
|
= help: the trait `Sync` is not implemented for `core::fmt::Opaque`
note: future is not `Send` as this value is used across an await
--> $DIR/src/test/ui/fmt/format-with-yield-point.rs:11:37
|
LL | println!("{} {:?}", "", async {}.await);
| --------------------------------^^^^^^-
| | |
| | await occurs here, with `$crate::format_args_nl!($($arg)*)` maybe used later
| has type `ArgumentV1<'_>` which is not `Send`
| `$crate::format_args_nl!($($arg)*)` is later dropped here
note: required by a bound in `assert_send`
--> $DIR/src/test/ui/fmt/format-with-yield-point.rs:18:24
|
LL | fn assert_send(_: impl Send) {}
| ^^^^ required by this bound in `assert_send`
error: future cannot be sent between threads safely
--> $DIR/src/test/ui/fmt/format-with-yield-point.rs:22:17
|
LL | assert_send(with_macro_call());
| ^^^^^^^^^^^^^^^^^ future returned by `with_macro_call` is not `Send`
|
= help: the trait `Sync` is not implemented for `core::fmt::Opaque`
note: future is not `Send` as this value is used across an await
--> $DIR/src/test/ui/fmt/format-with-yield-point.rs:6:17
|
LL | async {}.await
| ^^^^^^ await occurs here, with `$crate::format_args_nl!($($arg)*)` maybe used later
...
LL | println!("{} {:?}", "", m!());
| -----------------------------
| | |
| | in this macro invocation
| has type `ArgumentV1<'_>` which is not `Send`
| `$crate::format_args_nl!($($arg)*)` is later dropped here
note: required by a bound in `assert_send`
--> $DIR/src/test/ui/fmt/format-with-yield-point.rs:18:24
|
LL | fn assert_send(_: impl Send) {}
| ^^^^ required by this bound in `assert_send`
= note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to 2 previous errors
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Works as expected, and there are widespread reports of success with it,
as well as interest in it.
|
|
|
|
|
|
|
|
Warn when an escaped newline skips multiple lines
Resolves #87319
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
From what I can tell, the goal of the tests is to ensure that the error
formatting is correct. I think this is still being tested as intended
after this change.
|
|
* Always point at macros, including derive macros
* Point at non-local items that introduce a trait requirement
* On private associated item, point at definition
|
|
|
|
|
|
When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.
|
|
|
