decline to lint technically-unnecessary parens in function or method arguments inside of nested macros
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
Tweak presentation on lifetime trait mismatch
- On trait/impl method discrepancy, add label pointing at trait signature.
- Point only at method definition when referring to named lifetimes on lifetime mismatch.
- When the sub and sup expectations are the same, tweak the output to avoid repeated spans.
Fix#30790, CC #18759.
Sometimes the parser attempts to synthesize spans from within a macro
context with the span for the captured argument, leading to non-sensical
spans with very bad output. Given that an incorrect span is worse than
a partially incomplete span, when detecting this situation return only
one of the spans without mergin them.
Fix regression: account for trait methods in arg count mismatch error
Fixed#47706 (https://github.com/rust-lang/rust/issues/47706#issuecomment-361161495)
Original PR #47747 missed methods on trait definitions.
This edit was done in GitHub. I think I got the signature of the variant right, going by the ICE debug output and the other cases above.
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
Add line numbers and columns to error messages spanning multiple files
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
syntax: Lower priority of `+` in `impl Trait`/`dyn Trait`
Now you have to write `Fn() -> (impl A + B)` instead of `Fn() -> impl A + B`, this is consistent with priority of `+` in trait objects (`Fn() -> A + B` means `(Fn() -> A) + B`).
To make this viable I changed the syntax to also permit `+` in return types in function declarations
```
fn f() -> dyn A + B { ... } // OK, don't have to write `-> (dyn A + B)`
// This is acceptable, because `dyn A + B` here is an isolated type and
// not part of a larger type with various operator priorities in play
// like `dyn A + B` in `Fn() -> dyn A + B` despite syntax similarities.
```
but you still have to use `-> (dyn A + B)` in function types and function-like trait object types (see this PR's tests for examples).
This can be a breaking change for code using `impl Trait` on nightly. The thing that is most likely to break is `&impl A + B`, it needs to be rewritten as `&(impl A + B)`.
cc https://github.com/rust-lang/rust/issues/34511https://github.com/rust-lang/rust/issues/44662https://github.com/rust-lang/rfcs/pull/438
- On mismatch between impl and trait method, point at the trait
signature.
- Point only at the method signature instead of the whole body on
trait/impl mismatch errors.
When refering to named lifetime conflict, point only at the method's
signature span instead of the entire method.
When the expected and found sup and sub traces are the same, avoid
redundant text.
Correctly format `extern crate` conflict resolution help
Closes#45799. Follow up to @Cldfire's #45820.
If the `extern` statement that will have a suggestion ends on a `;`, synthesize a new span that doesn't include it.
For E0277 on `for` loops, point at the "head" expression
When E0277's span points at a `for` loop, the actual issue is in the
element being iterated. Instead of pointing at the entire loop, point
only at the first line (when possible) so that the span ends in the
element for which E0277 was triggered.
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
do not ICE when return type includes unconstrained anon region
It turns out that this *can* happen after all, if the region is only
used in projections from the input types.
Fixes https://github.com/rust-lang/rust/issues/47511
r? @eddyb
Fix spans in unused import lint for nested groups
This fixes an inconsistency for empty nested groups, and adds a test for all the possible cases of the lint.
```
warning: unused imports: `*`, `Foo`, `baz::{}`, `foobar::*`
--> test.rs:16:11
|
16 | use foo::{Foo, bar::{baz::{}, foobar::*}, *};
| ^^^ ^^^^^^^ ^^^^^^^^^ ^
|
= note: #[warn(unused_imports)] on by default
warning: unused import: `*`
--> test.rs:17:24
|
17 | use foo::bar::baz::{*, *};
| ^
warning: unused import: `use foo::{};`
--> test.rs:18:1
|
18 | use foo::{};
| ^^^^^^^^^^^^
```
cc #44494
Fix into() cast paren check precedence
As discussed in #47699 the logic for determining if an expression needs parenthesis when suggesting an `.into()` cast is incorrect. Two broken examples from nightly are:
```
error[E0308]: mismatched types
--> main.rs:4:10
|
4 | test(foo as i8);
| ^^^^^^^^^ expected i32, found i8
help: you can cast an `i8` to `i32`, which will sign-extend the source value
|
4 | test(foo as i8.into());
|
```
```
error[E0308]: mismatched types
--> main.rs:4:10
|
4 | test(*foo);
| ^^^^ expected i32, found i8
help: you can cast an `i8` to `i32`, which will sign-extend the source value
|
4 | test(*foo.into());
|
```
As suggested by @petrochenkov switch the precedence check to `PREC_POSTFIX`. This catches both `as` and unary operators. Fixes#47699.
r? @petrochenkov
