mirror of
https://github.com/rust-lang/rust.git
synced 2025-10-02 18:27:37 +00:00
99196657fc
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`. We add support for shortening the path of "trait path only". Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem). When we don't actually print out a shortened type we don't need the "use `--verbose`" note. On E0599 show type identity to avoid expanding the receiver's generic parameters. Unify wording on `long_ty_path` everywhere.
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<T>`
|
|
}
|