Skip to content

Compile error with ambiguous shortcut import resolving #1228

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
lht opened this issue Nov 30, 2011 · 7 comments
Closed

Compile error with ambiguous shortcut import resolving #1228

lht opened this issue Nov 30, 2011 · 7 comments

Comments

@lht
Copy link
Contributor

lht commented Nov 30, 2011

mod foo {
  mod bar {
    mod foo {
      fn i() {}
    }
  }
  mod baz {
      fn x() {
      }
  }
}

fn main() {
    import foo::baz;
    import foo::bar::foo;
}
imp.rs:14:4: 14:19 error: unresolved import: baz
imp.rs:14     import foo::baz;
              ^~~~~~~~~~~~~~~
error: aborting due to previous errors
rust: upcall fail 'explicit failure', ../src/comp/driver/session.rs:70
rust: domain main @0x97dee28 root task failed

It would be nice to suggest using an alias instead of complaining an "unresolved" error.

@brson
Copy link
Contributor

brson commented Dec 1, 2011

Wow. This is stunningly counter-intuitive behavior. Removing import foo::bar::foo makes it work as expected.

@lht
Copy link
Contributor Author

lht commented Dec 1, 2011

I run into this when I did "import rustc::driver::rustc;". Now I have something like "import rc = rustc::driver::rustc;", but figured that out took me some time. :)

@marijnh
Copy link
Contributor

marijnh commented Dec 1, 2011

Maybe imports should have ordered scope? In that they can't see themselves or imports coming after them. That would solve this and remove the need for the (current) exception that imports ignore themselves when resolving.

@lht
Copy link
Contributor Author

lht commented Dec 1, 2011

If wrote like:

    import foo::bar::foo;
    import foo::baz;

then it will still try to resolve the second import as foo::bar::foo::baz. We might need some precedences here, like always search from the root first, or at least gives a warning that some names are shadowed.

@marijnh
Copy link
Contributor

marijnh commented Dec 1, 2011

I disagree. It is quite clear to me that if you explicitly import something named foo, you are setting the local name foo to point at that thing. Searching twice, once from the root and once from the local package, seems too magical. It also won't work in all cases, since you'll often be importing in this style not from the root, but from some nearer parent scope.

@lht
Copy link
Contributor Author

lht commented Dec 1, 2011

Yes, that makes more sense. Only it may not be that obvious when crate name is involved.

import rustc::driver::rustc;
import ...;
...
...
import rustc::syntax::parse;

I will be happy if full name is given in error:

error: unresolved import: rustc::driver::rustc::syntax

@brson brson closed this as completed Dec 1, 2011
@brson brson reopened this Dec 1, 2011
@brson
Copy link
Contributor

brson commented Dec 1, 2011

I like both those ideas - resolve them in order and show what the compiler thought it was looking for.

marijnh added a commit that referenced this issue Dec 2, 2011
This broke no code at all, so I guess people were already writing
imports in this style.

Issue #1228
@marijnh marijnh closed this as completed Dec 2, 2011
bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2020
New Lint: `wildcard imports`

Fixes rust-lang#1228

### A few notes:
- I put this lint in the pedantic group, even though in the issue restriction was mentioned.
- Every fallout fix was automatically applied by `cargo fix` (This produced 3 `unused_imports` warnings) and are in commit 7e834c8. So reverting these changes wouldn't be a problem.

### A few ideas:
- A configuration to specify the amount of imported Items, where a `*` might be better.
- ~~A configuration to disable the lint for enums. Or just disable the lint for enums, since there is [`enum_glob_use`](https://rust-lang.github.io/rust-clippy/master/index.html#enum_glob_use)~~ I moved `enum_glob_use` into this lint in 12937f0

### A few quotes from the issue:
> Is there a way to ask the compiler about the modules or symbols that the current file is using?

Yes there is. I found it, once I was nearly finished implementing it myself. See 321d64a

> one hard optional feature would be to figure out what is currently used and add a suggestion to replace it with a full import list.

Yeah that was pretty hard, until I found the query for this. Queries are cool, but too hard to find.

> FWIW VS Code and Intellij IDEA both offer imports deglobbing which replace * with required imports.

And now, Clippy can do this too! 🎉

---

Your thoughts on the notes/ideas?

changelog: Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`]
coastalwhite pushed a commit to coastalwhite/rust that referenced this issue Aug 5, 2023
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
* Implement `arith_offset` with `codegen_offset`

* Extend `codegen_offset` args with `intrinsic`

* Add tests for `arith_offset`/`wrapping_offset`

* Improve documentation for `codegen_offset`

* Link issue and extend comment
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
Co-authored-by: Yuki Okushi <[email protected]>
Co-authored-by: nhamovitz <[email protected]>
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
Co-authored-by: Yuki Okushi <[email protected]>
Co-authored-by: nhamovitz <[email protected]>
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

No branches or pull requests

3 participants