Skip to content

Make error messages from deriving(Foo) point to the deriving declaration as well as the field #10844

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

Merged
merged 3 commits into from
Dec 7, 2013

Conversation

huonw
Copy link
Member

@huonw huonw commented Dec 7, 2013

Previously something like

struct NotEq;

#[deriving(Eq)]
struct Error {
    foo: NotEq
}

would just point to the foo field, with no mention of the
deriving(Eq). With this patch, the compiler creates a note saying "in
expansion of #[deriving(Eq)]" pointing to the Eq.

(includes some cleanup/preparation; the commit view might be nicer, to filter out the noise of the first one.)

huonw added 3 commits December 7, 2013 11:57
format.

Previously, any attempt to use this information from inside something
like #[deriving(Foo)] would result in it printing like `deriving(Foo)!`.
using the expansion info.

Previously something like

    struct NotEq;

    #[deriving(Eq)]
    struct Error {
        foo: NotEq
    }

would just point to the `foo` field, with no mention of the
`deriving(Eq)`. With this patch, the compiler creates a note saying "in
expansion of #[deriving(Eq)]" pointing to the Eq.
@huonw
Copy link
Member Author

huonw commented Dec 7, 2013

The test runner doesn't seem to handle //~ NOTE, hence no tests. :(

bors added a commit that referenced this pull request Dec 7, 2013
Previously something like

    struct NotEq;

    #[deriving(Eq)]
    struct Error {
        foo: NotEq
    }

would just point to the `foo` field, with no mention of the
`deriving(Eq)`. With this patch, the compiler creates a note saying "in
expansion of #[deriving(Eq)]" pointing to the Eq.

(includes some cleanup/preparation; the commit view might be nicer, to filter out the noise of the first one.)
@bors bors closed this Dec 7, 2013
@bors bors merged commit 0c0e73e into rust-lang:master Dec 7, 2013
@huonw huonw deleted the deriving-expn-info branch February 25, 2014 05:28
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jan 11, 2024
Don't lint `let_unit_value` when `()` is explicit

since these are explicitly written (and not the result of a function call or anything else), they should be allowed, as they are both useful in some cases described in rust-lang#9048

Fixes rust-lang#9048

changelog: [`let_unit_value`]: Don't lint when `()` is explicit
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants