-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework diagnostics for wrong number of generic args (fixes #66228 and #71924) #77524
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
17ca2ab
to
ea0a68d
Compare
Ping, ping, just remindin' - @matthewjasper :-) |
☔ The latest upstream changes (presumably #77926) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
also, re-pinging @matthewjasper :-) |
☔ The latest upstream changes (presumably #78127) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
☔ The latest upstream changes (presumably #77187) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
r? @estebank |
ping ping @estebank |
☔ The latest upstream changes (presumably #79070) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
ec2b6ea
to
1028d4f
Compare
ping ping @estebank, @jonas-schievink? (sorry, I'm not quite sure who to ping or how to proceed from here 😅) |
The triage working group would pick this up if it doesn't get updated in a while, but every time you comment that time gets reset |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for the delay in reviewing. I'll finish the review shortly, but in order to avoid keeping you waiting any further giving the length of the PR, I am pushing out some of the things I've found so far.
LL | trait Trait {} | ||
| ----------- defined here, with 0 type parameters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<3
src/test/ui/unboxed-closures/unboxed-closure-sugar-wrong-trait.stderr
Outdated
Show resolved
Hide resolved
src/test/ui/unboxed-closures/unboxed-closure-sugar-wrong-number-number-type-parameters.stderr
Outdated
Show resolved
Hide resolved
format!("consider removing this {} argument", self.kind) | ||
}; | ||
|
||
err.span_suggestion(span, &msg, String::new(), Applicability::MaybeIncorrect); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if making this
err.span_suggestion(span, &msg, String::new(), Applicability::MaybeIncorrect); | |
err.span_suggestion_verbose(span, &msg, String::new(), Applicability::MaybeIncorrect); |
will look better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like span_suggestion_verbose()
prints message with the suggestion already applied, yielding pearls such as:
@@ -19,7 +19,12 @@ LL | fn foo<const X: usize, const Y: usize>() -> usize {
| ------------------------------------------------- defined here, with 2 const parameters: `X`, `Y`
...
LL | foo::<0, 0, 0>();
- | ^^^ --- help: remove this const argument
+ | ^^^
+ |
+help: remove this const argument
+ |
+LL | foo::<0, 0>();
+ | --
or
@@ -25,7 +30,12 @@ LL | struct S;
| --------- defined here, with 0 const parameters
...
LL | S::<0>;
- | ^ - help: remove this const argument
+ | ^
+ |
+help: remove this const argument
+ |
+LL | S::<>;
+ | --
IMHO the inline (current) version with s/consider replacing/replace
is way more legible.
compiler/rustc_typeck/src/structured_errors/wrong_number_of_generic_args.rs
Outdated
Show resolved
Hide resolved
The job Click to see the possible cause of the failure (guessed by this bot)
|
@@ -1,8 +1,16 @@ | |||
error[E0107]: wrong number of type arguments: expected 0, found 1 | |||
error[E0107]: this trait takes 0 type arguments but 1 type argument was supplied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would give the error for non-Fn trait using parenthetical notation
higher priority and emit it instead of these two, but that should be done in a different PR.
help: use angle brackets to add missing type argument | ||
| | ||
LL | fn foo(b: Box<Bar<A>()>) { | ||
| ^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of the (incorrect) use of the parenthetical notation here, the suggestion is incorrect. That being said it might be worth it to tackle it at another time.
note: function defined here, with 2 generic parameters: `T`, `P` | ||
--> $DIR/issue-76595.rs:10:4 | ||
| | ||
LL | fn test<T, const P: usize>() where Bool<{core::mem::size_of::<T>() > 4}>: True { | ||
| ^^^^ - - | ||
help: add missing generic argument | ||
| | ||
LL | test::<2, P>(); | ||
| ^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see here that we don't try to match and differentiate between type, lifetime and const params, but that is fine for this PR, I'd like to land it sooner rather than later. We'll have to take a look at refining that later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the first version of this message did distinguish between type, lifetime and const parameters; it was changed some time ago on the upstream:
"generic" |
... and I just went with it.
help: add missing lifetime argument | ||
| | ||
LL | S::<'static, 'b>(&0, &0); | ||
| ^^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For lifetimes we would ideally look for available lifetimes (like we do in other cases) and if none use 'static
, but again, that should be follow up work. (I'm just marking TODO notes for later right now.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parallel idea: for lifetime & type generics in expression position (e.g. .collect::<Vec>()
) we could suggest using placeholders (i.e. suggest Vec<_>
instead of Vec<T>
).
error[E0107]: this struct takes 0 lifetime arguments but 1 lifetime argument was supplied | ||
--> $DIR/wrong-number-of-args.rs:10:14 | ||
| | ||
LL | type C = Ty<'static, usize>; | ||
| ^^ --------- help: remove this lifetime argument | ||
| | | ||
| expected 0 lifetime arguments | ||
| | ||
note: struct defined here, with 0 lifetime parameters | ||
--> $DIR/wrong-number-of-args.rs:2:12 | ||
| | ||
LL | struct Ty; | ||
| ^^ | ||
|
||
error[E0107]: this struct takes 0 type arguments but 1 type argument was supplied | ||
--> $DIR/wrong-number-of-args.rs:10:14 | ||
| | ||
LL | type C = Ty<'static, usize>; | ||
| ^^ ------- help: remove this type argument | ||
| | | ||
| expected 0 type arguments | ||
| | ||
note: struct defined here, with 0 type parameters | ||
--> $DIR/wrong-number-of-args.rs:2:12 | ||
| | ||
LL | struct Ty; | ||
| ^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would tackle these two with the same error, suggesting to remove the entirety of the arguments at once, but again, this can be done later, it is not a regression.
error[E0107]: this trait takes 0 lifetime arguments but 1 lifetime argument was supplied | ||
--> $DIR/typeck-builtin-bound-type-parameters.rs:13:15 | ||
| | ||
LL | fn foo2<'a, T:Copy<'a, U>, U>(x: T) {} | ||
| ^^ unexpected lifetime argument | ||
| ^^^^ ---- help: remove this lifetime argument | ||
| | | ||
| expected 0 lifetime arguments | ||
| | ||
note: trait defined here, with 0 lifetime parameters | ||
--> $SRC_DIR/core/src/marker.rs:LL:COL | ||
| | ||
LL | pub trait Copy: Clone { | ||
| ^^^^ | ||
|
||
error[E0107]: wrong number of type arguments: expected 0, found 1 | ||
--> $DIR/typeck-builtin-bound-type-parameters.rs:14:24 | ||
error[E0107]: this trait takes 0 type arguments but 1 type argument was supplied | ||
--> $DIR/typeck-builtin-bound-type-parameters.rs:13:15 | ||
| | ||
LL | fn foo2<'a, T:Copy<'a, U>, U>(x: T) {} | ||
| ^ unexpected type argument | ||
| ^^^^ --- help: remove this type argument | ||
| | | ||
| expected 0 type arguments | ||
| | ||
note: trait defined here, with 0 type parameters | ||
--> $SRC_DIR/core/src/marker.rs:LL:COL | ||
| | ||
LL | pub trait Copy: Clone { | ||
| ^^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This case is somewhat unfortunate (because we would need to look at the whole thing and suggest removing both lifetimes and type params in one go, but we don't need to tackle it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about a dedicated message for when generics were provided where none were expected, something in the lines of:
error[E0107]: this trait is not generic
--> $DIR/typeck-builtin-bound-type-parameters.rs:13:15
|
LL | fn foo2<'a, T:Copy<'a, U>, U>(x: T) {}
| ^^^^------- help: remove these generics
|
note: trait defined here, with no generics
--> $SRC_DIR/core/src/marker.rs:LL:COL
|
LL | pub trait Copy: Clone {
| ^^^^
I'll try tackling it in another PR, after this one gets merged :-)
| | ||
note: tuple variant defined here | ||
--> $DIR/enum-variant-priority-higher-than-other-inherent.rs:5:5 | ||
| | ||
LL | V(u8) | ||
| ^^^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somewhat surprised by this change 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's a bit unfortunate side effect of looking up identifiers via a new query - def_ident_span
- that I haven't been able to re-implement for tuple variants. Technically reviving this one should be as easy as improving that query.
@bors r+ rollup=never |
📌 Commit d2f8e39 has been approved by |
☀️ Test successful - checks-actions |
Rework diagnostics for wrong number of generic args (fixes rust-lang#66228 and rust-lang#71924) This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
This PR reworks the
wrong number of {} arguments
message, so that it provides more details and contextual hints.