Skip to content
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

Erroneously returning E0404 instead of E0245 #36337

Closed
mark-i-m opened this issue Sep 8, 2016 · 14 comments
Closed

Erroneously returning E0404 instead of E0245 #36337

mark-i-m opened this issue Sep 8, 2016 · 14 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@mark-i-m
Copy link
Member

mark-i-m commented Sep 8, 2016

I was working on #32777 and trying to generate E0245. I came up with the following example:

struct Foo(u8);

fn foo<T>(t: T)
    where T: Foo {
}

I believe this should return E0245, as Foo is not a trait, so it cannot be used as a bound. However, the compiler gives error E404, which states that Foo is not a trait, so it cannot be implemented for a type (according to https://doc.rust-lang.org/error-index.html#E0404).

@durka
Copy link
Contributor

durka commented Sep 8, 2016

Hmm, is it actually possible to generate E0245‽ It is generated in typeck, but E0404 is generated in resolve, which seems like an impenetrable barrier.

@TimNN
Copy link
Contributor

TimNN commented Sep 8, 2016

So here is my take on the situation:

  • I believe that E0404 is the correct error, it's just that the long explanation of E0404 needs to be updated
  • E0245 is a fatal error, it should be impossible to trigger
  • Looking at the code surrounding E0245, I think it is impossible to trigger E0245 without a bug elsewhere in the compiler

@durka
Copy link
Contributor

durka commented Sep 8, 2016

@TimNN we should probably remove E0245 then, or replace the code that currently generates it with an ICE and correctly decide between E0245/E0404 in resolve. E0404 is also generated for e.g. impl i32 for u32 {}, which is a different situation where the current long text matches.

@TimNN
Copy link
Contributor

TimNN commented Sep 8, 2016

@durka Yes, I agree. I think we basically have two separate issues:

  • E0245 should be a span bug
  • E0404 should be split into two error codes:
    • non-trait type used in impl Foo for (this situation is currently documented in the long text)
    • non-trait type used as a bound (this needs to be documented)

I'm not sure whether E0245 should be reused for the second case or rather whether a new error code should be introduced.

@mark-i-m
Copy link
Member Author

mark-i-m commented Sep 8, 2016

It seems that if E0245 is actually an unrelated error, it might make sense to create a new error code.

@mark-i-m
Copy link
Member Author

mark-i-m commented Sep 8, 2016

By the way, anyone know if it is also impossible to get E0103 and E0104?

@mark-i-m
Copy link
Member Author

Was there ever any consensus on this? I completely forgot about this thread.

@Mark-Simulacrum Mark-Simulacrum added the A-diagnostics Area: Messages for errors, warnings, and lints label May 19, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@mark-i-m
Copy link
Member Author

mark-i-m commented Sep 2, 2017

@Mark-Simulacrum should I close this? I have no idea if this is still even an up-to-date issue... #32777 was already closed.

@Mark-Simulacrum
Copy link
Member

I think this is fine to keep open at least for now.

@estebank
Copy link
Contributor

A note should be added for this case explaining that only traits can be trait bounds and if you want to use a struct in a method definition, it should be used directly where the type argument appears.

@mark-i-m
Copy link
Member Author

@estebank I'm still a bit lost. What should happen to both error codes? Should any new error codes be added? I'm glad to try to implement this, but I'm not sure what needs to be done.

@estebank
Copy link
Contributor

245 should be removed if there's no way to reach it. Either adding a new more specific error code or modifying the error code description would be fine, leaning towards the first.

@mark-i-m
Copy link
Member Author

Thanks @estebank ! I will look into it.

@mark-i-m
Copy link
Member Author

Made a PR, but it is failing tests, and I don't understand why. Help would appreciated :)

Manishearth added a commit to Manishearth/rust that referenced this issue Mar 1, 2018
Remove E0245; improve E0404

Fix rust-lang#36337

Somehow this is currently breaking --explain, but I don't understand how.

r? @estebank
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

5 participants