-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Fix nonsense non-tupled Fn
trait error
#99942
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix nonsense non-tupled Fn
trait error
#99942
Conversation
r? @cjgillot (rust-highfive has picked a reviewer for you, use r? to override) |
Fn
trait error
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.
Sorry for the delay @compiler-errors.
When we have Fn<A>
with a concrete type A
, we should probably report that a tuple is expected. The diagnostic improvement for generic A
is great though.
@@ -0,0 +1,8 @@ | |||
#![feature(unboxed_closures)] | |||
|
|||
fn a<F: Fn<usize>>(f: F) {} |
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.
Shouldn't we just report that a tuple is expected and bail out?
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.
Well making this a hard error in #99943, so I don't want to just introduce a special case error logic here.
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.
Also, reporting that a tuple is expected and bailing out is not gonna work when you have a generic Fn<T>
where T
is a type param.
_ => vec![ArgKind::empty()], | ||
_ => { | ||
not_tupled = true; | ||
vec![ArgKind::empty()] |
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.
Why do we keep a single ArgKind::empty()
, like 1-tuples, instead of an empty vec?
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.
No particular reason, I can fix that I guess.
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.
Oh, I know why. This code also handles Generator<T>
which takes a generic argument that isn't a tupled set of arguments.
@rustbot author |
I actually don't know if I have anything to change here. See replied comments. @rustbot ready |
@bors r+ |
…fn-trait-error, r=cjgillot Fix nonsense non-tupled `Fn` trait error Given this code: ```rust #![feature(unboxed_closures)] fn a<F: Fn<usize>>(f: F) {} fn main() { a(|_: usize| {}); } ``` We currently emit this error: ``` error[E0631]: type mismatch in closure arguments --> src/main.rs:6:5 | 6 | a(|_: usize| {}); | ^ ---------- found signature of `fn(usize) -> _` | | | expected signature of `fn(usize) -> _` | note: required by a bound in `a` --> src/main.rs:3:9 | 3 | fn a<F: Fn<usize>>(f: F) {} | ^^^^^^^^^ required by this bound in `a` For more information about this error, try `rustc --explain E0631`. error: could not compile `playground` due to previous error ``` Notably, it says the same thing for "expected" and "found"! Fix the output so that we instead emit: ``` error[E0308]: mismatched types --> /home/gh-compiler-errors/test.rs:6:5 | 6 | a(|_: usize| {}); | ^ types differ | = note: expected trait `Fn<usize>` found trait `Fn<(usize,)>` note: required by a bound in `a` --> /home/gh-compiler-errors/test.rs:3:9 | 3 | fn a<F: Fn<usize>>(f: F) {} | ^^^^^^^^^ required by this bound in `a` error: aborting due to previous error ``` The error could still use some work, namely the "mismatched types" part, but I'm leaving it a bit rough since the only way you'd ever get this error is when you're messing with `#![feature(unboxed_closures)]`. Simply making sure we actually print out the difference in trait-refs is good enough for me. I could probably factor in some additional improvements if those are desired.
@bors r-
|
9e52d22
to
1c084f1
Compare
@bors r=cjgillot |
Rollup of 6 pull requests Successful merges: - rust-lang#99942 (Fix nonsense non-tupled `Fn` trait error) - rust-lang#100609 (Extend invalid floating point literal suffix suggestion) - rust-lang#100610 (Ast and parser tweaks) - rust-lang#100613 (compiletest: fix typo in runtest.rs) - rust-lang#100616 (:arrow_up: rust-analyzer) - rust-lang#100622 (Support 128-bit atomics on all aarch64 targets) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Given this code:
We currently emit this error:
Notably, it says the same thing for "expected" and "found"!
Fix the output so that we instead emit:
The error could still use some work, namely the "mismatched types" part, but I'm leaving it a bit rough since the only way you'd ever get this error is when you're messing with
#![feature(unboxed_closures)]
.Simply making sure we actually print out the difference in trait-refs is good enough for me. I could probably factor in some additional improvements if those are desired.