Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diagnostic message for std trait implementation includes unstable std type #108994

Open
ChrisDenton opened this issue Mar 10, 2023 · 2 comments
Open
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ChrisDenton
Copy link
Member

Background

Within std I'm attempting to add an unstable type to a trait (see here for the impl). However, after compiling the new std, the unstable type is shown in error messages even without the feature enabled.

Code

struct Biscuits;
fn main() {
    std::fs::metadata(&Biscuits).unwrap();
}

Current Output

error[E0277]: the trait bound `Biscuits: AsRef<Path>` is not satisfied
    --> temp.rs:3:21
     |
3    |     std::fs::metadata(&Biscuits).unwrap();
     |     -----------------  ^^^^^^^^ the trait `AsRef<Path>` is not implemented for `Biscuits`
     |     |
     |     required by a bound introduced by this call
     |
     = help: the trait `AsPath` is implemented for `&NativePath`
     = note: required for `&Biscuits` to implement `AsRef<Path>`
     = note: required for `&Biscuits` to implement `AsPath`
note: required by a bound in `std::fs::metadata`
    --> R:\rust\library\std\src\fs.rs:1848:20
     |
1848 | pub fn metadata<P: AsPath>(path: P) -> io::Result<Metadata> {
     |                    ^^^^^^ required by this bound in `metadata`

Desired Output

Remove the first help: message.

error[E0277]: the trait bound `Biscuits: AsRef<Path>` is not satisfied
    --> temp.rs:3:21
     |
3    |     std::fs::metadata(&Biscuits).unwrap();
     |     -----------------  ^^^^^^^^ the trait `AsRef<Path>` is not implemented for `Biscuits`
     |     |
     |     required by a bound introduced by this call
     |
     = note: required for `&Biscuits` to implement `AsRef<Path>`
     = note: required for `&Biscuits` to implement `AsPath`
note: required by a bound in `std::fs::metadata`
    --> R:\rust\library\std\src\fs.rs:1848:20
     |
1848 | pub fn metadata<P: AsPath>(path: P) -> io::Result<Metadata> {
     |                    ^^^^^^ required by this bound in `metadata`
@ChrisDenton ChrisDenton added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 10, 2023
@jyn514
Copy link
Member

jyn514 commented Mar 10, 2023

this reminds me of #44026

@workingjubilee workingjubilee added the A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` label Mar 11, 2023
@ChrisDenton
Copy link
Member Author

I had a very quick look at this. A simple fix would be something like:

diff --git a/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs b/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
index 704b0d0bd1c..541cd4981e8 100644
--- a/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
+++ b/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
@@ -2101,6 +2101,10 @@ fn report_similar_impl_candidates(
                     }
                     // Avoid mentioning types that are private to another crate
                     else if let ty::Adt(def, _) = self_ty.peel_refs().kind() {
+                        // Avoid mentioning unstable types on stable
+                        if !self.tcx.sess.opts.unstable_features.is_nightly_build() && self.tcx.has_attr(def.did(), sym::unstable) {
+                            return false;
+                        }
                         // FIXME(compiler-errors): This could be generalized, both to
                         // be more granular, and probably look past other `#[fundamental]`
                         // types, too.

But I don't know if this is the best fix or if it would have any side effects. It would also need a test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants