diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2025-01-28 18:17:27 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-01-28 18:17:27 +0100 |
| commit | da49fcdbb4da3149f8dcc6868f0cb1d43da04442 (patch) | |
| tree | f876392fe94ef3c22c981dde64f80297e820c1f7 /tests | |
| parent | d43e78d6eaede16edc5cd398c102021903507d38 (diff) | |
| parent | d898aa3c334efacb64295f1dd36cfd50e0a74e9d (diff) | |
| download | rust-da49fcdbb4da3149f8dcc6868f0cb1d43da04442.tar.gz rust-da49fcdbb4da3149f8dcc6868f0cb1d43da04442.zip | |
Rollup merge of #136124 - adetaylor:test-comment, r=compiler-errors
Arbitrary self types v2: explain test. The purpose of this test wasn't obvious, as ```@traviscross``` noted. Add a comment. Confession: although this test was added to demonstrate this particular corner-case, I can no longer reproduce the original problem, even if I adjust `rustc` to do the "wrong" thing. I have spent several hours trying to adjust the case to trigger the "faulty" behavior with no success. This test may therefore not be as useful as it originally was. But it still seems worthwhile retaining as a regression test that we don't break things in these quirky circumstances. Ideally we'd find a new test which tests this behavior but I've failed to come up with one. r? ```@traviscross```
Diffstat (limited to 'tests')
| -rw-r--r-- | tests/ui/self/arbitrary_self_types_recursive_receiver.rs | 24 |
1 files changed, 23 insertions, 1 deletions
diff --git a/tests/ui/self/arbitrary_self_types_recursive_receiver.rs b/tests/ui/self/arbitrary_self_types_recursive_receiver.rs index f3e7f96d7c4..8b1b6a8a105 100644 --- a/tests/ui/self/arbitrary_self_types_recursive_receiver.rs +++ b/tests/ui/self/arbitrary_self_types_recursive_receiver.rs @@ -1,6 +1,22 @@ //@ run-pass #![feature(arbitrary_self_types)] +// When probing for methods, we step forward through a chain of types. The first +// few of those steps can be reached by jumping through the chain of Derefs or the +// chain of Receivers. Later steps can only be reached by following the chain of +// Receivers. For instance, supposing A and B implement both Receiver and Deref, +// while C and D implement only Receiver: +// +// Type A<B<C<D<E>>>> +// +// Deref chain: A -> B -> C +// Receiver chain: A -> B -> C -> D -> E +// +// We report bad type errors from the end of the chain. But at the end of which +// chain? We never morph the type as far as E so the correct behavior is to +// report errors from point C, i.e. the end of the Deref chain. This test case +// ensures we do that. + struct MyNonNull<T>(*const T); impl<T> std::ops::Receiver for MyNonNull<T> { @@ -10,7 +26,13 @@ impl<T> std::ops::Receiver for MyNonNull<T> { #[allow(dead_code)] impl<T> MyNonNull<T> { fn foo<U>(&self) -> *const U { - self.cast::<U>().bar() + let mnn = self.cast::<U>(); + // The following method call is the point of this test. + // If probe.rs reported errors from the last type discovered + // in the Receiver chain, it would be sad here because U is just + // a type variable. But this is a valid call so it ensures + // probe.rs doesn't make that mistake. + mnn.bar() } fn cast<U>(&self) -> MyNonNull<U> { MyNonNull(self.0 as *const U) |
