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).
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:
@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:
impl Foo for (this situation is currently documented in the long text)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 :)
Most helpful comment
@durka Yes, I agree. I think we basically have two separate issues:
impl Foo for(this situation is currently documented in the long text)I'm not sure whether E0245 should be reused for the second case or rather whether a new error code should be introduced.