Skip to content

deriving error should point to field which caused the error #7724

New issue

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

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

Already on GitHub? # to your account

Closed
metajack opened this issue Jul 11, 2013 · 5 comments · Fixed by #10355
Closed

deriving error should point to field which caused the error #7724

metajack opened this issue Jul 11, 2013 · 5 comments · Fixed by #10355
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-syntaxext Area: Syntax extensions

Comments

@metajack
Copy link
Contributor

Compiling the following:

struct Foo {
    foo: bool,
}

#[deriving(Clone)]
struct Bar {
    foo: Foo,
}

fn main() {
    let a = Bar { foo: Foo { foo: true }};
    a.clone();
}

produces

clonespan.rs:5:11: 5:16 error: mismatched types: expected `Foo` but found `&Foo` (expected struct Foo but found &-ptr)
clonespan.rs:5 #[deriving(Clone)]
                          ^~~~~

The real error is that Foo doesn't implement Clone. The span should also probably point to Foo in the definition for Bar instead of to the deriving line.

@metajack
Copy link
Contributor Author

metajack commented Aug 8, 2013

I ran into another case of this error a few days ago. It went something like this:

use std::libc::c_void;

pub type Foo = c_void;

#[deriving(Clone)]
struct Bar {
  priv foo: *Foo,
}

Maybe this is just a missing Clone impl for raw pointers. Or perhaps this pattern is specifically not supported. I didn't have time to look but figured I'd update this bug.

@emberian
Copy link
Member

emberian commented Nov 4, 2013

This is going to be hard, I think. But, maybe not. Perhaps the deriving could rewrite the span to the originating field?

cc @huonw

@huonw
Copy link
Member

huonw commented Nov 5, 2013

It shouldn't be too hard; I'll look at it tonight.

@huonw
Copy link
Member

huonw commented Nov 7, 2013

(I have looked at it, I've got a patch compiling, but it'll take me a day or two to polish it off... I did it properly and started moving syntax::ext::deriving off its tuple addiction onto some more structs.)

@huonw
Copy link
Member

huonw commented Nov 8, 2013

See #10355.

Unfortunately the only implementation that's possible right now means that the error doesn't mention the deriving at all, i.e. it just points at the field. I think that is the appropriate trade-off, but others may disagree...

bors added a commit that referenced this issue Nov 8, 2013
This rearranges the deriving code so that #[deriving] a trait on a field
that doesn't implement that trait will point to the field in question,
e.g.

    struct NotEq; // doesn't implement Eq

    #[deriving(Eq)]
    struct Foo {
        ok: int,
        also_ok: ~str,
        bad: NotEq // error points here.
    }

Unfortunately, this means the error is disconnected from the `deriving`
itself but there's no current way to pass that information through to
rustc except via the spans, at the moment.

Fixes #7724.
@huonw huonw closed this as completed in 812ea9e Nov 8, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 18, 2022
…arth

Add `std_instead_of_core`, `std_instead_of_alloc`, `alloc_instead_of_core`

Closes rust-lang#7724

Introduces 3 new lints:
- `std_instead_of_core` - lints items resolved through `std` which are available in `core`
- `std_instead_of_alloc` - lints items resolved through `std` which are available in `alloc`
- `alloc_instead_of_core` - lints items resolved through `alloc` which are available in `core`

Though the original issue only mentions `std_instead_of_alloc`, the other two lints could be useful as well.

questions:
- what do I call the file the lints live in? I was thinking `std_reexports`?

changelog: new lint's: [`std_instead_of_core`], [`std_instead_of_alloc`], [`alloc_instead_of_core`]
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-syntaxext Area: Syntax extensions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants