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 https://github.com/rust-lang/rust/issues/126989 for this.