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

Declaring modules inside decl macros 2.0 #46342

Closed
valff opened this issue Nov 28, 2017 · 8 comments
Closed

Declaring modules inside decl macros 2.0 #46342

valff opened this issue Nov 28, 2017 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros-2.0 Area: Declarative macros 2.0 (#39412) A-resolve Area: Name resolution C-bug Category: This is a bug. F-decl_macro `#![feature(decl_macro)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@valff
Copy link
Contributor

valff commented Nov 28, 2017

Not sure if it is a bug or confusing error messages. Consider the following code:
Playground

#![feature(decl_macro)]

macro impl_mod($name:ident) {
  pub mod $name {
    pub struct Bar;
  }
}

impl_mod!(foo);

use foo::Bar;

fn main() {}

Output:

error[E0432]: unresolved import `foo::Bar`
  --> src/main.rs:11:5
   |
11 | use foo::Bar;
   |     ^^^^^^^^ no `Bar` in `foo`. Did you mean to use `Bar`?

warning: unused import: `foo::Bar`
  --> src/main.rs:11:5
   |
11 | use foo::Bar;
   |     ^^^^^^^^
   |
   = note: #[warn(unused_imports)] on by default

What is confusing:

  1. So is it unresolved or resolved and unused?
  2. "no 'Bar'. did you mean 'Bar'?" - feels like a bug.
  3. Path foo is accessible, why then foo::Bar not?

rustc --version --verbose:

rustc 1.24.0-nightly (560a5da9f 2017-11-27)
binary: rustc
commit-hash: 560a5da9f1cc7f67d2fc372925aef18c96c82629
commit-date: 2017-11-27
host: x86_64-unknown-linux-gnu
release: 1.24.0-nightly
LLVM version: 4.0
@petrochenkov
Copy link
Contributor

unresolved import `foo::Bar` / no `Bar` in `foo`

Name Bar defined in the macro is protected by hygiene 2.0 and cannot be named from the outside, therefore the error. (Name foo is defined outside of the macro, so it can be used from outside of the macro as well.)

Did you mean to use Bar?

This is a diagnostic bug, inaccessible names like Bar should be filtered away before giving advices.

unused import: `foo::Bar`

Diagnostic bug as well, erroneous imports should not be reported as unused.

@valff
Copy link
Contributor Author

valff commented Nov 28, 2017

Name Bar defined in the macro is protected by hygiene 2.0 and cannot be named from the outside, therefore the error.

Makes sense. But it still can be exported and named by crate consumers. Is it how intended? Maybe a separate bug?

@petrochenkov
Copy link
Contributor

But it still can be exported and named by crate consumers.

Do you mean foo::Bar is accessible from other crates?
Then it looks like a bug. Bar shouldn't be accessible anywhere outside of macro impl_mod.

@valff
Copy link
Contributor Author

valff commented Nov 28, 2017

Do you mean foo::Bar is accessible from other crates?
Then it looks like a bug. Bar shouldn't be accessible anywhere outside of macro impl_mod.

Yes. Then here is a minimal example: https://github.com/valff/hygiene_bug

@petrochenkov
Copy link
Contributor

I see.
IIRC, cross-crate hygiene (i.e. storing hygiene related data in metadata of compiled crates) isn't fully implemented yet.

@valff
Copy link
Contributor Author

valff commented Nov 28, 2017

Ok, now it is clear for me. Thank you for your time!

@petrochenkov
Copy link
Contributor

There are some legitimate issues reported here.

@petrochenkov petrochenkov reopened this Jan 23, 2018
@petrochenkov petrochenkov added A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution A-macros-2.0 Area: Declarative macros 2.0 (#39412) labels Jan 23, 2018
@XAMPPRocky XAMPPRocky added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Feb 19, 2018
@Centril Centril added the F-decl_macro `#![feature(decl_macro)]` label Sep 28, 2019
@fmease
Copy link
Member

fmease commented Oct 2, 2023

This no longer emits the incorrect suggestion did you mean …?:

error[E0432]: unresolved import `foo::Bar`
  --> src/main.rs:11:5
   |
11 | use foo::Bar;
   |     ^^^^^^^^ no `Bar` in `foo`

Therefore I consider this fixed unless you'd like to see a note explaining def-site hygiene?
Closing for now but feel free to raise objections and I can reopen it.

Edit: Fixed by #90202.

@fmease fmease closed this as completed Oct 2, 2023
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 A-macros-2.0 Area: Declarative macros 2.0 (#39412) A-resolve Area: Name resolution C-bug Category: This is a bug. F-decl_macro `#![feature(decl_macro)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants