-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.D-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.D-terseDiagnostics: An error or lint that doesn't give enough information about the problem at hand.Diagnostics: An error or lint that doesn't give enough information about the problem at hand.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.requires-nightlyThis issue requires a nightly compiler in some way.This issue requires a nightly compiler in some way.
Description
#![feature(fn_traits)]
struct S;
impl Fn(u32) -> u32 for S {
fn call(&self) -> u32 {
5
}
}
fn main() {
}
This yields:
error[E0229]: associated type bindings are not allowed here
--> foo2.rs:5:17
|
5 | impl Fn(u32) -> u32 for S {
| ^^^ associate type not allowed here
error: aborting due to previous error
Which is extremely confusing and non-actionable.
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.D-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.D-terseDiagnostics: An error or lint that doesn't give enough information about the problem at hand.Diagnostics: An error or lint that doesn't give enough information about the problem at hand.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.requires-nightlyThis issue requires a nightly compiler in some way.This issue requires a nightly compiler in some way.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
jdm commentedon Jan 23, 2017
cc @jrmuizel
durka commentedon Jan 23, 2017
It is sort of actionable if you know that
Fn(u32) -> u32
really meansFn<(u32,), Output=u32>
. Let's put that expansion in a note on the error message I guess?BGR360 commentedon Dec 29, 2021
This code now produces two confusing errors:
In the first one, the erroneous span has moved inside of the parentheses, so I feel it's no longer as correct as it used to be, and no more helpful.
And the second one just seems... incorrect? Idk, I'm not intimately familiar with this nightly feature.
@rustbot label +D-confusing +D-terse +requires-nightly +D-incorrect
estebank commentedon Jan 8, 2023
Current output:
Ezrashaw commentedon Jan 9, 2023
My understanding of this issue is that the
impl Fn(u32) -> u32
is expanded toimpl Fn<(u32, ), Output = u32>
whereOutput
is not allowed and must be moved elsewhere.Two issues currently seem to exist:
Fn(u32) -> u32
->Fn<(u32, ), Output = u32>
) forfn_traits
is not shown. This can be addressed by adding a note to the error message.E0229
doesn't suggest a moving the associated type, this needs a proper suggestion and should be discussed more.I'll work on 1. 2 seems out of scope of this issue.
@rustbot claim
estebank commentedon Jan 9, 2023
@Ezrashaw if you're able to detect that you've got
Fn
trait syntax in theTrait
part of theimp
item, you should be able to print the type directly (to get the desugared version) and mention in passing "includetype Output = u32
in theimpl
body instead" or something like that.Ezrashaw commentedon Jan 9, 2023
@estebank Isn't that suggestion generic to all "assoc type not allowed here" error?
estebank commentedon Jan 10, 2023
Come to think of it, It would be.
Ezrashaw commentedon Jan 11, 2023
Hmm, @estebank I think I've run into a problem: I cannot print the type. The error occurs is emitted from
rustc_hir_analysis
and so ype checking hasn't been done yet.estebank commentedon Jan 11, 2023
Because this is a nightly feature, I would side step the issue by not mentioning the type for now and only mention the "represent the closure with the regular trait syntax instead and move the output
type
to the body this way", but it should be easy to come up with a mechanism to translate from one syntax to the other (if it doesn't exist already!), while not having to rely onty::*
, only on the AST and resolve.Fn*
traits #108930Rollup merge of rust-lang#108930 - Ezrashaw:better-error-for-manual-f…