| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fixes #94646
|
|
Change location of where clause on GATs
Closes #89122
~Blocked on lang FCP~
r? `@nikomatsakis`
|
|
|
|
TaKO8Ki:suggest-removing-semicolon-after-derive-attribute, r=cjgillot
Suggest removing a semicolon after derive attributes
closes #93942
|
|
use current token span
|
|
Follow up to #92746. Address #94510.
|
|
then we just suggest the first legal position where you could inject a use.
To do this, I added `inject_use_span` field to `ModSpans`, and populate it in
parser (it is the span of the first token found after inner attributes, if any).
Then I rewrote the use-suggestion code to utilize it, and threw out some stuff
that is now unnecessary with this in place. (I think the result is easier to
understand.)
Then I added a test of issue 87613.
|
|
|
|
|
|
|
|
4 - Make more use of `let_chains`
Continuation of #94376.
cc #53667
|
|
* Recover from invalid `'label: ` before block.
* Make suggestion to enclose statements in a block multipart.
* Point at `match`, `while`, `loop` and `unsafe` keywords when failing
to parse their expression.
* Do not suggest `{ ; }`.
* Do not suggest `|` when very unlikely to be what was wanted (in `let`
statements).
|
|
Continuation of #94376.
cc #53667
|
|
|
|
diagnostic: suggest parens when users want logical ops, but get closures
Fixes #93536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adopt let else in more places
Continuation of #89933, #91018, #91481, #93046, #93590, #94011.
I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This is the biggest of these PRs and handles the changes outside of rustdoc, rustc_typeck, rustc_const_eval, rustc_trait_selection, which were handled in PRs #94139, #94142, #94143, #94144.
|
|
|
|
compiler: clippy::complexity fixes
useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref
|
|
Even more let_else adoptions
Continuation of #89933, #91018, #91481, #93046, #93590.
|
|
|
|
i'd guess about 70% of "bad escape" cases occur when someone meant to
use a raw string literal because they're passing it directly to
Regex::new(). this emits an advisory (Applicability::MaybeIncorrect)
help: suggestion to the user that they use an r"" string,
on top of the normal notes about looking at the
string literal documentation/spec.
|
|
fix ICE when parsing lifetime as function argument
I don't really like this, but we basically need to emit an error instead of just delaying an bug, because there are too many places in the AST that aren't covered by my previous PRs...
cc: https://github.com/rust-lang/rust/issues/93282#issuecomment-1028052945
|
|
useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref
|
|
single_char_pattern and to_string_in_format_args
|
|
|
|
|
|
If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase
The current error for this case isn't really great, it just complains about the whole thing past the `0` being an invalid suffix.
|
|
|
|
Improve suggestion for escaping reserved keywords
r? `@davidtwco`
|
|
|
|
|
|
Incorporate distance limit from `find_best_match_for_name` directly into
Levenshtein distance computation.
Use the string size difference as a lower bound on the distance and exit
early when it exceeds the specified limit.
After finding a candidate within a limit, lower the limit further to
restrict the search space.
|
|
|
|
|
|
|
|
Let qpath contain NtTy: `<$:ty as $:ty>::…`
Example:
```rust
macro_rules! m {
(<$type:ty as $trait:ty>::$name:ident) => {
<$type as $trait>::$name
};
}
fn main() {
let _: m!(<str as ToOwned>::Owned);
}
```
Previous behavior:
```console
error: expected identifier, found `ToOwned`
--> src/main.rs:3:19
|
3 | <$type as $trait>::$name
| ^^^^^^ expected identifier
...
8 | let _: m!(<str as ToOwned>::Owned);
| ---------------------------
| |
| this macro call doesn't expand to a type
| in this macro invocation
```
The <code>expected identifier, found \`ToOwned\`</code> error is particularly silly. I think it should be fine to accept this code as long as $trait is of the form `TyKind::Path(None, path)`; if it is any other kind of `NtTy`, we'll keep the same behavior as before.
|
|
Also prevent ICE when adding a const in associated const equality.
|
|
ProjectionPredicate should be able to handle both associated types and consts so this adds the
first step of that. It mainly just pipes types all the way down, not entirely sure how to handle
consts, but hopefully that'll come with time.
|
|
Instead of having a separate enum variant for types and consts have one but have either a const
or type.
|
|
|
|
r=nagisa
Fix suggesting turbofish with lifetime arguments
Now we suggest turbofish correctly given exprs like `foo<'_>`.
Also fix suggestion when we have `let x = foo<bar, baz>;` which was broken.
|
|
Parse `Ty?` as `Option<Ty>` and provide structured suggestion
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
|
|
|
