Change:
The full log is available from this link: From the aforementioned link:
Do you have a more concise way of reproducing this? I can't seem to get it to ICE when I run with , no matter if I use , etc.
nvm, should be using ..
This is actually reproducible even with . It seems to only ICE with feature. Command for reproduction: <details<summary<strongBacktrace</strong</summary<p</p</detailsWe don't use feature much, so it should be easy, to make a MRE, I'll try.
I found an MRE. I'll put up a fix in a second.
I found a MRE too :(
+1, I basically reproduced that in the UI test but manually expanding the part of the macro that causes the ICE.

Discussion:
} } ty::Error(_) => ControlFlow::Break(OrphanCheckEarlyExit::LocalTy(ty)), <del> ty::Opaque(..) | ty::Closure(..) | ty::Generator(..) | ty::GeneratorWitness(..) => { </del> <ins> ty::Closure(..) | ty::Generator(..) | ty::GeneratorWitness(..) => { </ins> self.tcx.sess.delay_span_bug( DUMMY_SP, format!("ty_is_local invoked on closure or generator: {:?}", ty), ); ControlFlow::Break(OrphanCheckEarlyExit::LocalTy(ty)) } <ins> ty::Opaque(..) => { // This merits some explanation. // Normally, opaque types are not involved when performing // coherence checking, since it is illegal to directly // implement a trait on an opaque type. However, we might // end up looking at an opaque type during coherence checking // if an opaque type gets used within another type (e.g. as // the type of a field) when checking for auto trait or `Sized` // impls. This requires us to decide whether or not an opaque // type should be considered 'local' or not. // // We choose to treat all opaque types as non-local, even // those that appear within the same crate. This seems // somewhat surprising at first, but makes sense when // you consider that opaque types are supposed to hide // the underlying type *within the same crate*. When an // opaque type is used from outside the module // where it is declared, it should be impossible to observe // anything about it other than the traits that it implements. // // The alternative would be to look at the underlying type // to determine whether or not the opaque type itself should // be considered local. However, this could make it a breaking change // to switch the underlying ('defining') type from a local type // to a remote type. This would violate the rule that opaque // types should be completely opaque apart from the traits // that they implement, so we don't use this behavior. self.found_non_local_ty(ty) } </ins> }; // A bit of a hack, the `OrphanChecker` is only used to visit a `TraitRef`, so // the first type we visit is always the self type.

<ins> // check-pass #![feature(type_alias_impl_trait)] struct Outer<T: ?Sized> { i: InnerSend<T>, } type InnerSend<T: ?Sized> = impl Send; fn constrain<T: ?Sized>() -> InnerSend<T> { () } trait SendMustNotImplDrop {} #[allow(drop_bounds)] impl<T: ?Sized + Send + Drop> SendMustNotImplDrop for T {} impl<T: ?Sized> SendMustNotImplDrop for Outer<T> {} fn main() {} </ins>

<ins> // check-pass #![feature(type_alias_impl_trait)] struct Send<T> { i: InnerSend<T>, } type InnerSend<T> = impl Sized; fn constrain<T>() -> InnerSend<T> { () } trait SendMustNotImplDrop {} #[allow(drop_bounds)] impl<T: Drop> SendMustNotImplDrop for T {} impl<T> SendMustNotImplDrop for Send<T> {} fn main() {} </ins>

LL | impl AnotherTrait for D<OpaqueType> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `D<OpaqueType>` | <del> = note: downstream crates may implement trait `std::fmt::Debug` for type `OpaqueType` </del> <ins> = note: upstream crates may add a new impl of trait `std::fmt::Debug` for type `OpaqueType` in future versions </ins> error: cannot implement trait on type alias impl trait --> $DIR/negative-reasoning.rs:19:25