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

No unused import for std::f64 if only f64 types used #40774

Open
johnthagen opened this issue Mar 23, 2017 · 1 comment
Open

No unused import for std::f64 if only f64 types used #40774

johnthagen opened this issue Mar 23, 2017 · 1 comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@johnthagen
Copy link
Contributor

I recently came across several instances of the following problem in a code base:

use std::f64; // No warning.

fn main() {
    let x: f64 = 0.0;
    println!("{}", x);
}

Why this didn't cause a warning baffled me for a while, until I realize that it was actually imported the type f64, even though I had been using it up until that point as a module like:

use std::f64;

fn main() {
    println!("{}", f64::consts::PI);
}

Then later, when I refactored the code (more complex than this toy example), something like this was left:

use std::f64; // No warning for "unused" import, but it is not necessary.
use std::f64::consts::PI;

fn main() {
    let x: f64 = 0.0;
    println!("{}", PI + x);
}

In this final case, it would be great if rustc warned about this since f64 is always implicitly in scope as a primitive type (I didn't think you could actually import it?).

Is this a case where the unused import lint got confused incorrectly?

@petrochenkov petrochenkov added A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name resolution labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 27, 2017
@torhovland
Copy link
Contributor

I had a look at this, but was unable to come up with a fix.

In resolve_ident_in_module_unadjusted_ext there is a:

self.record_use(ident, binding, restricted_shadowing);

One idea would be to do:

if PrimTy::from_name(ident.name).is_none() {
    self.record_use(ident, binding, restricted_shadowing);
}

But this doesn't work, because ident.name is simply f64 also for the usage that we want to record.

@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name resolution C-bug Category: This is a bug. 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

5 participants