Skip to content

Inconsistent path resolution between 'use' and expressions in 2018 #57853

Closed
@brson

Description

@brson

I don't know the details of "path clarity" and "uniform paths", but I would expect that path resolution in use statements and expressions would work the same. And they do in all situations I've tested except for these two involving external crates:

#![allow(warnings)]
extern crate tokio;

mod a {
    mod tokio { pub mod prelude {
        pub enum Async { NotReady, BlahBlahBlah }
        pub struct NotInTokio;
    } }
    
    // root takes precedence in 2015;
    // ambiguous in 2018, and with uniform_paths
    // use tokio::prelude::Async;
    // failed root resolution in 2015;
    // ambiguous in 2018, and with uniform_paths
    // use tokio::prelude::NotInTokio;
    
    fn f() {
        // _local scope_ takes precedence in 2015, 2018, uniform_paths;
        // inconsistent with 'use' in 2018
        let _ = tokio::prelude::Async::NotReady;
        // local scope in all versions, inconsistent like above
        let _ = tokio::prelude::NotInTokio;
    }
}

The two use statements are ambiguous in 2018, but the two expressions resolve to the local module. I'd expect the expressions to be ambiguous.

Tested in 1.32 and whatever nightly is on playground today.

Playground

Activity

brson

brson commented on Jan 23, 2019

@brson
ContributorAuthor

I tested this with and without the uniform_paths feature but have since been told that uniform_paths is stable, contrary to the edition guide.

brson

brson commented on Jan 23, 2019

@brson
ContributorAuthor
petrochenkov

petrochenkov commented on Jan 23, 2019

@petrochenkov
Contributor

@brson

I would expect that path resolution in use statements and expressions would work the same.

The important clarification is that resolution works the same if there are no errors.
Paths in use can produce extra errors compared to non-use paths.
use tokio in the example is one of those extra errors (namely, an ambiguity error).

The good news is this specific error is not technically necessary, but rather introduced for ideological reasons ("ambiguity is bad"), and it can be removed making import paths closer to other paths.
The tracking issue for this ambiguity removal is #56414.

petrochenkov

petrochenkov commented on Jan 23, 2019

@petrochenkov
Contributor

(Some "true" errors exist as well, e.g. you certainly cannot use paths to associated items in imports.)

added
A-diagnosticsArea: Messages for errors, warnings, and lints
A-resolveArea: Name/path resolution done by `rustc_resolve` specifically
on Jan 24, 2019
added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Jan 28, 2019
brson

brson commented on Feb 10, 2019

@brson
ContributorAuthor

Thanks for the clarifications @petrochenkov. Is there any actual bug here or should this be closed?

petrochenkov

petrochenkov commented on Feb 10, 2019

@petrochenkov
Contributor

No rustc bug, some missing documentation in the edition-guide or reference perhaps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsA-resolveArea: Name/path resolution done by `rustc_resolve` specificallyT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @brson@estebank@jonas-schievink@petrochenkov

        Issue actions

          Inconsistent path resolution between 'use' and expressions in 2018 · Issue #57853 · rust-lang/rust