Fails to resolve associated types correctly in trait impls if the concrete type is in another crate

[sdroege]

See https://github.com/sdroege/rust-associated-types-from-other-crate-projection-bug

The following are the relevant parts of the code:

https://github.com/sdroege/rust-associated-types-from-other-crate-projection-bug/blob/5586433d247734d0efdb73cf51f9b8b9ecde1852/bar/src/lib.rs#L7-L16

https://github.com/sdroege/rust-associated-types-from-other-crate-projection-bug/blob/5586433d247734d0efdb73cf51f9b8b9ecde1852/bar/src/lib.rs#L28-L38

In summary it seems like impl Something<<Foo as Mapper>::OtherType> for Baz {} works fine as long as Foo is defined in the same crate, otherwise it maps the Foo (for whatever reason) to Baz itself.

@alexcrichton

[alexcrichton]

cc @rust-lang/compiler, seems like a scary compiler bug! Is there perhaps an issue already open for this?

[arielb1]

This isn't as spooky as it appears at first glance. This is not a soundness issue (coherence rejects code that is not unsound) or a weird bug:

The problem is that, because of the future-compatibility orphan rules, coherence is not allowed to know whether Foo: Mapper holds (type not local, trait not local and not fundamental), and, as a consequence, it is not allowed to normalize (or, in a post-lazy-normalization world, to know what types are equal to) <Foo as Mapper>::OtherType.

As such, this looks like nothing more than a somewhat-unexpected consequence of the orphan checking rules. I'm not sure whether this is the right thing to do or not - cc the trait guys @nikomatsakis @aturon @scalexm - but this is more of a language issue. Because this affects the API future-compatibility guarantee, I would expect this to at least be documented in an RFC amendment to rust-lang/rfcs#1023 either way we choose to go.

[arielb1]

On a second thought, the parent crate can't actually change the value of a preexisting associated type without causing obvious downstream breakage, so that's an argument for the code being allowed to compile. On the other hand, figuring out what this means probably requires the better control over "inference guessing" that Chalk gives us.

[nikomatsakis]

triage: P-medium

Marking as T-lang, I-nominated.

[nikomatsakis]

Removing nomination. I think we should consider revisiting this, but just in general as part of a push on cleaning up coherence + trait code.

[sdroege]

I just ran into this again in a different place. Is there any known way to work around this, or any plans/ideas how to fix it?

[lcnr]

this is a duplicate of #99940 which has more information about this bug, closing in favor of that one

thank you for opening this issue ❤️