Rust: Erroneously returning E0404 instead of E0245

Created on 8 Sep 2016  Â·  14Comments  Â·  Source: rust-lang/rust

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).

A-diagnostics C-enhancement

Most helpful comment

@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.

All 14 comments

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.

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

@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.

@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.

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

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

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

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

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

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.

@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.

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.

Thanks @estebank ! I will look into it.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

drewcrawford picture drewcrawford  Â·  3Comments

Robbepop picture Robbepop  Â·  3Comments

pedrohjordao picture pedrohjordao  Â·  3Comments

mcarton picture mcarton  Â·  3Comments

dwrensha picture dwrensha  Â·  3Comments