Skip to content

"Unused imports" warning has false-positives in the presence of syntax extensions #6371

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

Closed
catamorphism opened this issue May 9, 2013 · 6 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name/path resolution done by `rustc_resolve` specifically A-syntaxext Area: Syntax extensions

Comments

@catamorphism
Copy link
Contributor

For example, code with deriving(IterBytes) seems to need a use core; in scope. however, this causes a warning: unused import. Removing the import causes a resolve error, though.

Or maybe the answer is for syntax extensions to not require a certain module to be in scope... I'm not sure.

@catamorphism
Copy link
Contributor Author

Nominating for milestone 5, production-ready.

@alexcrichton
Copy link
Member

The emission of unused imports changed a fair amount in #6093, so this may be fixed by that. Is there a simple case that I can test one? I tried:

#[deriving(IterBytes)]
enum A{
  B, C, D
}

fn main(){}

and I didn't get any errors. This makes me think that it may only pertain to things with #[no_core] ?

@catamorphism
Copy link
Contributor Author

Hmm, maybe you do need #[no_core]. I'll try to make a test case.

@catamorphism
Copy link
Contributor Author

Yeah, @alexcrichton seems to be right. This only happens inside rustc. If you want to test it, try removing the use core; directive from librustc/middle/ty.rs.

rustc doesn't have #[no_core], though. I still don't know what's going on...

@alexcrichton
Copy link
Member

This doesn't look to be an error, just an unfortunate stage0 thing. If you add #[cfg(stage0)], the warning goes away. The reason for this is that the #[deriving(IterBytes)] attribute used to generated code of the form:

#[deriving(IterBytes)]
enum A { B, }
#[doc = "Automatically derived."]
pub impl ::core::to_bytes::IterBytes for A {
    pub fn iter_bytes(&self, __lsb0: bool, __f: core::to_bytes::Cb) {
        match *self { B => { 0u.iter_bytes(__lsb0, __f); } }; }
    }

whereas now it spits out

#[deriving(IterBytes)]
enum A { B, }
#[doc = "Automatically derived."]
pub impl ::core::to_bytes::IterBytes for A {
    pub fn iter_bytes(&self, __arg_0: ::bool, __arg_1: ::core::to_bytes::Cb)
     -> ::bool {
        match *self { B => 0u.iter_bytes(__arg_0, __arg_1) }
    }
}

Which if you notice on the second argument, the path was changed from a relative path to an absolute one, which would explain why in later stages the use core isn't needed, but in stage0 it is.

@catamorphism
Copy link
Contributor Author

Ah, ok. If it's a "this'll go away with the next snapshot" thing, then I'll be happy :-)

flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 6, 2020
Rustup

changelog: none

r? `@ghost`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name/path resolution done by `rustc_resolve` specifically A-syntaxext Area: Syntax extensions
Projects
None yet
Development

No branches or pull requests

2 participants