`rustc::traits::orphan_check_trait_ref` does not consider `TraitDef::is_marker`

[Centril]

It seems like #53693 did not update the orphan checker to consider #[marker] traits.

• Suppose I have crates A, B, C.
• A defines #[marker] trait Foo {}
• B defines struct Bar;
• C defines impl Foo for Bar {}

This should be OK because the overlap would actually be permitted as Foo is a #[marker] trait.

However, there might be something I've overlooked here such as impl polarity (impls_are_allowed_to_overlap) so I'm not filing a PR just now.

cc @nikomatsakis @arielb1 @scottmcm
cc #29864

References:

• https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html#structfield.is_marker
• https://doc.rust-lang.org/nightly/nightly-rustc/rustc/traits/coherence/fn.orphan_check_trait_ref.html

[nikomatsakis]

Hmm. This depends, I suppose, on the "role" of the orphan rules. Do they exist only to prevent overlap, or also to give a degree of "ownership" to the crate that defined Bar?

I suspect the answer should probably be the former, because the current rules don't actually give that much "ownership", especially for traits that have multiple input types. But I'm not entirely sure.

This same question arose in the context of the Pin unsoundness. In particular, as @withoutboats was telling me, they wanted to be able to reason about things like "there is no DerefMut impl for &T". I'm not crazy about this sort of "negative reasoning", as it is fragile -- it wen't wrong in the Pin case because of fundamental + dyn values. But in general if our orientation is to permit "third party crates" to add impls whenever we can get away with it, that is going to make such reasoning very difficult indeed.

[Centril]

I agree that orphan rules should be about preventing the potential for overlap.

In this specific case the user has marked the trait as #[marker] (and therefore it has no computational content and overlap is vacuously sound), so it seems to me that their intent was to allow this. Indeed, the reason I found this problem was that I wanted to move rustc::hir::ArenaAllocatable to rustc_arena, but couldn't because of the orphan rule.

As for DerefMut (which has computational content unlike a #[marker] trait), it seems to me that one can always retain such reasoning if one wishes by simply not using #[marker] for the specific trait. ;)

[matthewjasper]

Wouldn't this force us to consider that the following impl overlaps with anything?

impl <T: MarkerTrait> NonMarker for T {}

How is this supposed to interact with specialization?

[scottmcm]

Closing this as @rust-lang/lang FCPed in #96766 (comment) that #[marker] is not about orphan. (It's only about overlap.)