-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Ambiguity errors in 2018 uniform import paths are not technically necessary #56414
Comments
👍 for "remove ambiguity warnings for any case except local name versus extern crate". |
If I understand your proposal correctly, then I believe that the following example (albeit perhaps contrived) would render quite paradoxical: pub mod a { // outer decl
pub mod a {} // inner decl
}
pub mod b {
use super::*; // outer use
pub fn f() { // inner use
use a::*;
}
} How does the name In short: the outer declaration is only in scope, if it is not in scope. Or something like that :) FWIW, I am not a Rust programmer, so forgive me if I misunderstood the semantics or your proposal. I am interested in name binding semantics however and I figured the above example was worth keeping in mind. |
@ajrouvoet This example will likely cause the "glob import vs any other name from outer scope during import/macro resolution" error if the "name vs any other name during import resolution" restriction is removed. I can check today, the fix for this issue is a one-line change in the compiler (this |
Thanks for having a look; I'm very curious about this. I can see how the type-checker may guard against this specific scenarios. At the same time I wonder if one could still give a declarative semantics of name resolution in Rust for the result. It may be unwanted that name resolution can only be explained in the end in terms of what the implemented algorithm can/cannot resolve. This seems important for reasoning about the language, for explaining rust to programmers, but also for tools that strive for conformance with the reference rust compiler. |
It should certainly be possible to compact the specification of import resolution behavior into something shorter than its implementation in the compiler. The general idea behind the ambiguity errors in particular is that we report an error if some name in inner scope can "materialize" later (due to import dependencies, or macro expansion) than the same name in outer scope. #53778 (comment) describes how this general idea applies to macros. #![feature(decl_macro)]
mod m { pub macro a() {} }
macro a() {} // Outer scope
fn main() {
use m::*; // Inner scope
a!(); // error[E0659]: `a` is ambiguous (glob import vs any other name from outer scope during import/macro resolution)
} |
There's a similar issue when an item being imported has the same name as the path being used. mod users {
pub struct table;
pub mod dsl {
pub use super::table as users;
}
}
fn main() {
use users::dsl::*;
} Outputs:
An import should never be ambiguous with itself. |
We discussed this in today's @rust-lang/lang meeting. We think that this could potentially be removed at this point, given that we've long-since settled on a specific module-system model, but we'd like to confirm which cases still produce errors (in order to confirm that those errors aren't actually catching anything of value), and whether further changes have reduced the set of things that produce errors. |
Another way of putting this:
|
I implemented this change in #112086. |
resolve: Remove artificial import ambiguity errors Fixes rust-lang#56414. FCP report: rust-lang#112086 (comment)
This was changed in rust-lang/rust#56414 to favor in-scope items.
This was changed in rust-lang/rust#56414 to favor in-scope items.
This was changed in rust-lang/rust#56414 to favor in-scope items.
Right now import resolution on 2018 edition fails with an ambiguity error if multiple candidates are found:
This is different from non-import paths in which resolutions from closer scopes are preferred without errors.
This restriction is technically unnecessary and exists because some people were uncomfortable with disambiguation happening in import paths specifically (see previous threads, ... many of them, #55618 being the latest one).
This restriction can be lifted fully or partially if it causes too much trouble in practice with ambiguity errors, or with addition of new names to libraries being backward-incompatible due to new ambiguities.
(By "partially" I mean e.g. "disambiguation is okay, unless one of the candidates is an extern crate" or something like that.)
The text was updated successfully, but these errors were encountered: