Confusing diagnostic when attempting to implementing trait for tuple

[varkor]

impl std::ops::AddAssign for () {
    fn add_assign(&self, other: ()) -> () {
        ()
    }
}

produces:

error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
  --> src/lib.rs:12:1
   |
12 | impl std::ops::AddAssign for () {
   | ^^^^^-------------------^^^^^--
   | |    |                       |
   | |    |                       this is not defined in the current crate because tuples are always foreign
   | |    this is not defined in the current crate because tuples are always foreign
   | impl doesn't use only types from inside the current crate
   |
   = note: define and implement a trait or new type instead

Notice how it highlights std::ops::AddAssign and says this is not defined in the current crate because tuples are always foreign, despite AddAssign have nothing to do with tuples.

[estebank]

The change needs to be made somewhere in the logic of

rust/src/librustc_typeck/coherence/orphan.rs

Lines 39 to 80 in 0d2817a

	let mut err = struct_span_err!(
	self.tcx.sess,
	sp,
	E0117,
	"only traits defined in the current crate can be implemented for \
	arbitrary types"
	);
	err.span_label(sp, "impl doesn't use only types from inside the current crate");
	for (ty, is_target_ty) in &tys {
	let mut ty = *ty;
	self.tcx.infer_ctxt().enter(|infcx| {
	// Remove the lifetimes unnecessary for this error.
	ty = infcx.freshen(ty);
	});
	ty = match ty.kind {
	// Remove the type arguments from the output, as they are not relevant.
	// You can think of this as the reverse of `resolve_vars_if_possible`.
	// That way if we had `Vec<MyType>`, we will properly attribute the
	// problem to `Vec<T>` and avoid confusing the user if they were to see
	// `MyType` in the error.
	ty::Adt(def, _) => self.tcx.mk_adt(def, ty::List::empty()),
	_ => ty,
	};
	let this = "this".to_string();
	let (ty, postfix) = match &ty.kind {
	ty::Slice(_) => (this, " because slices are always foreign"),
	ty::Array(..) => (this, " because arrays are always foreign"),
	ty::Tuple(..) => (this, " because tuples are always foreign"),
	_ => (format!("`{}`", ty), ""),
	};
	let msg = format!("{} is not defined in the current crate{}", ty, postfix);
	if *is_target_ty {
	// Point at `D<A>` in `impl<A, B> for C<B> in D<A>`
	err.span_label(impl_ty.span, &msg);
	} else {
	// Point at `C<B>` in `impl<A, B> for C<B> in D<A>`
	err.span_label(tr.path.span, &msg);
	}
	}
	err.note("define and implement a trait or new type instead");
	err.emit();
	return;

The output should have been

error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
  --> src/lib.rs:12:1
   |
12 | impl std::ops::AddAssign for () {
   | ^^^^^-------------------^^^^^--
   | |    |                       |
   | |    |                       this is not defined in the current crate because tuples are always foreign
   | |    `std::ops::AddAssign` is not defined in the current crate
   | impl doesn't use only types from inside the current crate
   |
   = note: define and implement a trait or new type instead

[estebank]

I see why this happens: AddAssign has an Rhs type argument with a default type Self (AddAssign<Rhs = Self>) which means that what was written gets desugared internally to impl std::ops::AddAssign<Rhs=()> for () { /* ... */ }, which would have made more sense:

error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
  --> src/lib.rs:12:1
   |
12 | impl std::ops::AddAssign<Rhs=()> for () {
   | ^^^^^---------------------------^^^^^--
   | |    |                               |
   | |    |                               this is not defined in the current crate because tuples are always foreign
   | |    this is not defined in the current crate because tuples are always foreign
   | impl doesn't use only types from inside the current crate
   |
   = note: define and implement a trait or new type instead

[TroyNeubauer]

Would like to work on this. Excited for my first issue!
@rustbot claim

[estebank]

@TroyNeubauer you'll have to check whether the trait itself is foreign, and if so avoid adding the "because tuples are always foreign" and instead say "this is not defined in the current crate because this is a foreign trait".