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

meta not indicated as reserved crate name when shadowing module #73948

Closed
yodaldevoid opened this issue Jul 2, 2020 · 5 comments · Fixed by #75802
Closed

meta not indicated as reserved crate name when shadowing module #73948

yodaldevoid opened this issue Jul 2, 2020 · 5 comments · Fixed by #75802
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@yodaldevoid
Copy link
Contributor

yodaldevoid commented Jul 2, 2020

Taken from this internals thread: https://internals.rust-lang.org/t/is-the-module-name-meta-forbidden/9587

A module named meta is shadowed leading to misleading error messages. meta was reserved as a built-in crate name in 2018 edition, but the error message does not indicate this.

I tried this code:

mod meta {
    pub struct Thing;
}

use meta::Thing;

fn main() {}

Above code compiled with rustc --edition 2018 {file}

This is expected to indicated that meta is a reserved crate name.

Instead, the following error is reported:

error[E0463]: can't find crate for `meta`
 --> testy.rs:5:5
  |
5 | use meta::Thing;
  |     ^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.

Meta

rustc --version --verbose:

rustc 1.44.1 (c7087fe00 2020-06-17)
binary: rustc
commit-hash: c7087fe00d2ba919df1d813c040a5d47e43b0fe7
commit-date: 2020-06-17
host: x86_64-unknown-linux-gnu
release: 1.44.1
LLVM version: 9.0

This issue has been assigned to @Chocol4te via this comment.

@yodaldevoid yodaldevoid added the C-bug Category: This is a bug. label Jul 2, 2020
@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed C-bug Category: This is a bug. labels Jul 2, 2020
@fmckeogh
Copy link
Member

fmckeogh commented Jul 7, 2020

@rustbot claim

@rustbot
Copy link
Collaborator

rustbot commented Jul 7, 2020

Error: Parsing assign command in comment failed: ...'tbot claim' | error: expected end of command at >| ' ?'...

Please let @rust-lang/release know if you're having trouble with this bot.

@rustbot rustbot self-assigned this Jul 7, 2020
@fmckeogh
Copy link
Member

fmckeogh commented Jul 7, 2020

@rustbot claim

@rustbot rustbot assigned rustbot and unassigned rustbot Jul 7, 2020
@eddyb
Copy link
Member

eddyb commented Jul 11, 2020

It's not forbidden as a module name, this obviously works:

mod meta {
    pub struct Thing;
}

use crate::meta::Thing;

I think the confusion arises from that fact that this works without crate:::

mod foo {
    pub struct Thing;
}

use foo::Thing;

But those are uniform imports (or at least I think that's what they're called), and only resolve to the surrounding scope if unambiguous (which it is for meta due to the.

I'm guessing the right fix here is to add more information to the error suggesting that if the intention wasn't to refer to a crate, crate:: or self:: etc. should/can be used explicitly.

(EDIT: I went to the internals thread to reply, and it's from March 2019 apparently, and also crate:: was mentioned there, but I guess the fact that the name meta is perfectly fine outside of use meta::...; wasn't brought up)

cc @petrochenkov

@yodaldevoid
Copy link
Contributor Author

@eddyb

I believe the crate:: "fix" was mentioned in a reddit thread linking to the internals thread, but I forgot to mention it. I will reword the issue as it is misworded, as you pointed out. Lastly, what you suggested for a fix lines up with what I was expecting.

Also, now you know how deep my backlog of todo items is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
5 participants