Skip to content

Restrictions on imports of $crate are illogical #149811

@ijackson

Description

@ijackson

The restriction against importing $crate seems to be mis-implemented.

Consider this program https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=05c4fba76e41533e7b3ac8940aab1c87

macro_rules! t { {} => {

//  // error: `$crate` may not be imported
//  // good; this ought not to compile because what would it mean
//  use $crate;

//  compiles, good, this is a coherent thing to ask, although the syntax is clumsy.
    use $crate::{self as self_as_bracketed};

//  // error: `$crate` may not be imported
//  // restriction is illogical; this is just the same as above only with less faff
//  use $crate as crate_as;

//  // there doesn't seem to be any way to refer to this weird `self`
    #[expect(unused_imports)] 
//  compiles, WTF, this makes no sense and should be forbidden
    use $crate::{self}; // compiles, WTF

} }

t!();

const C: () = ();

pub fn chk() {
    let _ = self_as_bracketed::C; // works, as expected
    let _ = self::C; // this `self` isn't the one from the weird import in `t!`
}

I think use $crate as identifier ought to be accepted. The {self as ..} isn't adding anything other than to bypass the restriction.

Conversely use $crate::{self} is madness but is currently accepted. There might be compatibility implications of forbidding it, I guess - maybe some macro does that by mistake. It seems harmless so maybe it would be best just to continue to allow it. IDK.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyC-bugCategory: This is a bug.T-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

    Issue actions