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

Confusing error deriving PartialEq when child type impls PartialEq<OtherType> #63564

Open
cmyr opened this issue Aug 14, 2019 · 2 comments
Open
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@cmyr
Copy link

cmyr commented Aug 14, 2019

Compiling the following code

struct TypeA;
struct TypeB;

#[derive(PartialEq)]
struct TypeC(TypeA);

impl std::cmp::PartialEq<TypeA> for TypeB {
    fn eq(&self, other: &TypeA) -> bool { true }
}

impl std::cmp::PartialEq<TypeB> for TypeA {
    fn eq(&self, other: &TypeB) -> bool { true }
}


fn main() {
    let one = TypeC(TypeA);
    let two = TypeC(TypeA);
    if one == two {
        eprintln!("yay");
    }
}

produces,

error[E0308]: mismatched types
 --> src/main.rs:8:14
  |
8 | struct TypeC(TypeA);
  |              ^^^^^ expected struct `TypeB`, found struct `TypeA`
  |
  = note: expected type `TypeB`
             found type `TypeA`

Which I found very confusing. It would be helpful, at least, if we could indicate that this error occurred during macro expansion?

Playground here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ac13781b2c40c1966e18adfb919c236c

@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 14, 2019
@estebank
Copy link
Contributor

The built-in derive macros do not currently mark their spans with a ctxt. If we did that we could extend the type errors with that information and make it clear where the error is actually coming from.

@osa1
Copy link
Contributor

osa1 commented Mar 22, 2021

The built-in derive macros do not currently mark their spans with a ctxt.

@estebank Is this a limitation of an API, or just something we don't do but we could easily do?

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-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. 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

4 participants