PowerPC test failures due to "similarly named associated type"

[nikic]

There are a number of tests that fail on PowerPC, because the emit an additional "there is a similarly named associated type" note. This happens for tests where an unknown single-character associated type is used.

The reason this only happens on PowerPC is, apparently, that core::core_arch::powerpc::altivec::sealed::VectorRl happens to define a single-character associated type, which is considered "similar" to any other single character type.

I'm not sure what the best fix for this is -- adjust tests to use longer names? Adjust VectorRl::B to use a longer name? Make the note less aggressive?

---- [ui] tests/ui/associated-consts/assoc-const-eq-missing.rs stdout ----
diff of stderr:
8	  --> $DIR/assoc-const-eq-missing.rs:16:16
9	   |
10	LL | fn foo2<F: Foo<Z = usize>>() {}
-	   |                ^ associated type `Z` not found
+	   |                ^ there is a similarly named associated type `B` in the trait `core::core_arch::powerpc::altivec::sealed::VectorRl`
12	
13	error[E0220]: associated constant `Z` not found for `Foo`
14	  --> $DIR/assoc-const-eq-missing.rs:18:16


---- [ui] tests/ui/error-codes/E0220.rs stdout ----
diff of stderr:
2	  --> $DIR/E0220.rs:5:22
3	   |
4	LL | type Foo = dyn Trait<F=i32>;
-	   |                      ^ help: `Trait` has the following associated type: `Bar`
+	   |                      ^ there is a similarly named associated type `B` in the trait `core::core_arch::powerpc::altivec::sealed::VectorRl`
6	
7	error[E0191]: the value of the associated type `Bar` in `Trait` must be specified
8	  --> $DIR/E0220.rs:5:16

---- [ui] tests/ui/lifetimes/issue-95023.rs stdout ----
diff of stderr:
54	  --> $DIR/issue-95023.rs:8:44
55	   |
56	LL |     fn foo<const N: usize>(&self) -> Self::B<{ N }>;
-	   |                                            ^ help: `Self` has the following associated type: `Output`
+	   |                                            ^ there is an associated type `B` in the trait `core::core_arch::powerpc::altivec::sealed::VectorRl`
58	
59	error[E0220]: associated type `B` not found for `Self`
60	  --> $DIR/issue-95023.rs:8:44
61	   |
62	LL |     fn foo<const N: usize>(&self) -> Self::B<{ N }>;
-	   |                                            ^ help: `Self` has the following associated type: `Output`
+	   |                                            ^ there is an associated type `B` in the trait `core::core_arch::powerpc::altivec::sealed::VectorRl`
64	   |
65	   = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`


---- [ui] tests/rustdoc-ui/issues/issue-79465.rs stdout ----
diff of stderr:
2	  --> $DIR/issue-79465.rs:1:20
3	   |
4	LL | pub fn f1<T>(x: T::A) {}
-	   |                    ^ associated type `A` not found
+	   |                    ^ there is a similarly named associated type `B` in the trait `core::core_arch::powerpc::altivec::sealed::VectorRl`
+	   |
+	help: consider restricting type parameter `T`
+	   |
+	LL | pub fn f1<T: core::core_arch::powerpc::altivec::sealed::VectorRl>(x: T::A) {}
+	   |            +++++++++++++++++++++++++++++++++++++++++++++++++++++
+	help: and also change the associated type name
+	   |
+	LL | pub fn f1<T>(x: T::B) {}
+	   |                    ~
6	
7	error: aborting due to 1 previous error
8	

[workingjubilee]

cc @lu-zero

[lu-zero]

The intrinsics document name those parameters a, b, c, r, I can rename the associated types, but the diagnostic is digging very deep to hit that, would be good to add a knob to prevent it from going that far by default anyway?

[workingjubilee]

Yes, I think the levenshtein algorithm needs tuning.

[glaubitz]

Which PowerPC target triplet is this? I observed a high increase of testsuite failures on powerpc-unknown-linux-gnu after #118709.

Edit: I have filed #126989 for this.

[awilfox]

I'm seeing this on powerpc64-*-linux-musl, but only on tests/ui/lifetimes/issue-95023.rs.

[nikic]

The stdarch submodule hasn't been updated yet since this was fixed. #117468 should pull this in.

[awilfox]

Indeed, rust-lang/stdarch#1582 fixes that test when applied manually. Thanks for the pointer!