| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
relying on the span making it obvious
|
|
available
|
|
|
|
This shows a small note on what the macro matcher was currently
processing to aid with "no rules expected the token X" errors.
|
|
Expand potential inner `Or` pattern for THIR
Code assumed there wouldn't be a deeper `Or` pattern inside expanded `PatStack` this fixes it by looking for the `Or` pattern inside expanded `PatStack`.
A more ideal solution would be recursively doing this but I haven't found a good way to do that.
_fixes #97898_
|
|
|
|
|
|
|
|
|
|
|
|
the right path
|
|
|
|
|
|
|
|
|
|
Given
```rust
match Some(42) {
Some(0) => {}
}
```
suggest
```rust
match Some(42) {
Some(0) => {}
None | Some(_) => todo!(),
}
```
|
|
Given
```rust
match Some(42) {}
```
suggest
```rust
match Some(42) { None | Some(_) => todo!(), }
```
|
|
|
|
|
|
When encountering a binop where the types would have been accepted, if
all the predicates had been fulfilled, include information about the
predicates and suggest appropriate `#[derive]`s if possible.
Point at trait(s) that needs to be `impl`emented.
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.
|
|
|
|
|
|
|
|
|
|
Along the way, we also implement a handful of diagnostics improvements
and fixes, particularly with respect to the special handling of `||` in
place of `|` and when there are leading verts in function params, which
don't allow top-level or-patterns anyway.
|
|
Identify unreachable subpatterns more reliably
In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/80501 it was revealed that `Span`s are complicated and that this was not a good idea.
Instead, this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex, but thankfully self-contained; the rest of the code does not need to know anything about it.
Fixes https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral.
r? `@varkor`
|
|
|
|
|
|
|
|
|
|
|
|
or_patterns: implement :pat edition-specific behavior
cc #54883 `@joshtriplett`
This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090.
I believe this can unblock stabilization of or_patterns.
r? `@petrochenkov`
|
|
|
|
|
|
`SpanSet` is heavily inspired from `DefIdForest`.
|
|
|
|
|
|
This fixes https://github.com/rust-lang/rust/issues/76836
|
|
|
|
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.
|
|
|
|
|
|
propagation
|
|
|
|
Previously errors were sorted by Symbol index instead of the string. The
indexes are not the same between architectures because Symbols for
architecture extensions (e.g. x86 AVX or RISC-V d) are interned before
the source file is parsed. RISC-V's naming of extensions after single
letters led to it having errors sorted differently for test cases using
single letter variable names. Instead sort the errors by the Symbol
string so that it is stable across architectures.
|
|
Fix ICE for broken or-pattern in async fn
closes #71297
|
|
|
