Repository navigation
Diagnostics: suggest alternatives when new constructor is not available #69512
Description
Failing Code
Consider the following code:
use std::net::TcpStream;
fn main() {
let stream = TcpStream::new();
}This fails with an error that simply states that new is not available:
Compiling playground v0.0.1 (/playground)
error[E0599]: no function or associated item named `new` found for type `std::net::TcpStream` in the current scope
--> src/main.rs:4:28
|
4 | let stream = TcpStream::new();
| ^^^ function or associated item not found in `std::net::TcpStream`
error: aborting due to previous errorWorking Code
The intent is fairly clear: we want to construct a new TcpStream using a method that follows the Rust naming conventions for constructors, but that method is not available. Instead the solution is likely to be either TcpStream::connect or
TcpStream::connect_timeout:
use std::net::TcpStream;
fn main() {
let stream = TcpStream::connect("localhost:8080");
}Diagnostics Suggestions
When new is not available it'd be ideal if the compiler could suggest
alternatives. A first heuristic for which methods to suggest be methods on
the same struct that don't take any self params, have Self as their
return type, and aren't implemented through any trait.
For TcpStream this would include TcpStream::connect and
TcpStream::connect_timeout. But not TcpStream::try_clone,
TcpStream::from_raw_fd, TcpStream::from_raw_socket and
std::net::Incoming::next.
I'm not too sure how to structure the help message exactly, but I could
imagine something along these lines might work:
Compiling playground v0.0.1 (/playground)
error[E0599]: no function or associated item named `new` found for type `std::net::TcpStream` in the current scope
--> src/main.rs:4:28
|
4 | let stream = TcpStream::new();
| ^^^ function or associated item not found in `std::net::TcpStream`
= help: Did you mean to use `std::net::TcpStream::connect` or `std::net::TcpStream::connect_timeout`?
error: aborting due to previous errorcc/ @estebank
Activity
Centril commentedon Feb 27, 2020
Seems like
#[doc(alias(...))]es should be added to the standard library to fix this.varkor commentedon Feb 29, 2020
This seems to be the same as #51398.
Centril commentedon Feb 29, 2020
Closing in favor of that.
yoshuawuyts commentedon Mar 2, 2020
@Centril For the example I brought up, how would an
#[doc(alias(...))]work? Thenewmethod does not exist onTcpStream. So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into.While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
Centril commentedon Mar 2, 2020
No but
TcpStream::connectdoes exist, so e.g.,#[doc(alias(TcpStream::new))]on it could add the information necessary (see e.g.#[doc(alias = "memcpy")]oncopy_nonoverlapping) for the compiler to provide the diagnostic.But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
estebank commentedon Oct 21, 2023
@yoshuawuyts what do you think of the following?
When not finding assoc fn on type, look for builder fn
yoshuawuyts commentedon Oct 21, 2023
@estebank oh I love it!
When not finding assoc fn on type, look for builder fn
When not finding assoc fn on type, look for builder fn
When not finding assoc fn on type, look for builder fn
When not finding assoc fn on type, look for builder fn
When not finding assoc fn on type, look for builder fn
Auto merge of rust-lang#117006 - estebank:issue-69512, r=compiler-errors