mirror of
https://github.com/rust-lang/rust.git
synced 2025-04-29 19:47:38 +00:00
e75660dad3
In this new version of Arbitrary Self Types, we no longer use the Deref trait exclusively when working out which self types are valid. Instead, we follow a chain of Receiver traits. This enables methods to be called on smart pointer types which fundamentally cannot support Deref (for instance because they are wrappers for pointers that don't follow Rust's aliasing rules). This includes: * Changes to tests appropriately * New tests for: * The basics of the feature * Ensuring lifetime elision works properly * Generic Receivers * A copy of the method subst test enhanced with Receiver This is really the heart of the 'arbitrary self types v2' feature, and is the most critical commit in the current PR. Subsequent commits are focused on: * Detecting "shadowing" problems, where a smart pointer type can hide methods in the pointee. * Diagnostics and cleanup. Naming: in this commit, the "Autoderef" type is modified so that it no longer solely focuses on the "Deref" trait, but can now consider the "Receiver" trait instead. Should it be renamed, to something like "TraitFollower"? This was considered, but rejected, because * even in the Receiver case, it still considers built-in derefs * the name Autoderef is short and snappy.
49 lines
1.5 KiB
Rust
49 lines
1.5 KiB
Rust
//@ edition: 2018
|
|
|
|
#![feature(arbitrary_self_types)]
|
|
|
|
// tests that the referent type of a reference must be known to call methods on it
|
|
|
|
struct SmartPtr<T>(T);
|
|
|
|
impl<T> core::ops::Receiver for SmartPtr<T> {
|
|
type Target = T;
|
|
}
|
|
|
|
impl<T> SmartPtr<T> {
|
|
fn foo(&self) {}
|
|
}
|
|
|
|
fn main() {
|
|
let val = 1_u32;
|
|
let ptr = &val;
|
|
let _a: i32 = (ptr as &_).read();
|
|
//~^ ERROR type annotations needed
|
|
|
|
// Same again, but with a smart pointer type
|
|
let val2 = 1_u32;
|
|
let rc = std::rc::Rc::new(val2);
|
|
let _b = (rc as std::rc::Rc<_>).read();
|
|
//~^ ERROR type annotations needed
|
|
|
|
// Same again, but with a smart pointer type
|
|
let ptr = SmartPtr(val);
|
|
|
|
// We can call unambiguous outer-type methods on this
|
|
(ptr as SmartPtr<_>).foo();
|
|
// ... but we can't follow the Receiver chain to the inner type
|
|
// because we end up with _.
|
|
|
|
// Because SmartPtr implements Receiver, it's arguable which of the
|
|
// following two diagnostics we'd want in this case:
|
|
// (a) "type annotations needed" (because the inner type is _)
|
|
// (b) "no method named `read` found for struct `SmartPtr`"
|
|
// (ignoring the fact that there might have been methods on the
|
|
// inner type, had it not been _)
|
|
// At present we produce error type (b), which is necessary because
|
|
// our resolution logic needs to be able to call methods such as foo()
|
|
// on the outer type even if the inner type is ambiguous.
|
|
let _c = (ptr as SmartPtr<_>).read();
|
|
//~^ ERROR no method named `read` found for struct `SmartPtr`
|
|
}
|