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

2018 edition fails to import modules for binary projects #57252

Closed
ghost opened this issue Jan 2, 2019 · 3 comments · Fixed by #56759
Closed

2018 edition fails to import modules for binary projects #57252

ghost opened this issue Jan 2, 2019 · 3 comments · Fixed by #56759
Labels
A-resolve Area: Name resolution

Comments

@ghost
Copy link

ghost commented Jan 2, 2019

Hello Rust developers,

My project is a binary project:

├── Cargo.lock
├── Cargo.toml
├── src
    ├── a.rs
    ├── main.rs
    └── z.rs

Without edition = "2018", my imports work:

mod a;
mod z;

With edition = "2018", above imports don't work. Prefixing crate::a or self::a doesn't work either.

Error message is:

error[E0658]: imports can only refer to extern crate names passed with `--extern` on stable channel (see issue #53130)
  --> src/main.rs:13:5
   |
1  | mod a;
   | ------ not an extern crate passed with `--extern`

I stripped down the error message at line #13, it's just use a::something;.

I think it's a bug, may I ask if you could verify?

Thank you,

@Centril
Copy link
Contributor

Centril commented Jan 2, 2019

cc @petrochenkov

@Centril Centril added the A-resolve Area: Name resolution label Jan 2, 2019
@petrochenkov
Copy link
Contributor

This is correct behavior in the "anchored path" model which is currently in effect on stable.
Going to be fixed once #56759 lands.

@ghost
Copy link
Author

ghost commented Jan 2, 2019

Thank you, I'm closing this issue.

@ghost ghost closed this as completed Jan 2, 2019
bors added a commit that referenced this issue Jan 12, 2019
Stabilize `uniform_paths`

Address all the things described in #56417.

Assign visibilities to `macro_rules` items - `pub` to `macro_export`-ed macros and `pub(crate)` to non-exported macros, these visibilities determine how far these macros can be reexported with `use`.

Prohibit use of reexported inert attributes and "tool modules", after renaming (e.g. `use inline as imported_inline`) their respective tools and even compiler passes won't be able to recognize and properly check them.

Also turn use of uniform paths in 2015 macros into an error, I'd prefer to neither remove nor stabilize them right away because I still want to make some experiments in this area (uniform path fallback was added to 2015 macros used on 2018 edition in #56053 (comment)).

UPDATE: The last commit also stabilizes the feature `uniform_paths`.

Closes #53130
Closes #55618
Closes #56326
Closes #56398
Closes #56417
Closes #56821
Closes #57252
Closes #57422
bors added a commit that referenced this issue Jan 12, 2019
Stabilize `uniform_paths`

Address all the things described in #56417.

Assign visibilities to `macro_rules` items - `pub` to `macro_export`-ed macros and `pub(crate)` to non-exported macros, these visibilities determine how far these macros can be reexported with `use`.

Prohibit use of reexported inert attributes and "tool modules", after renaming (e.g. `use inline as imported_inline`) their respective tools and even compiler passes won't be able to recognize and properly check them.

Also turn use of uniform paths in 2015 macros into an error, I'd prefer to neither remove nor stabilize them right away because I still want to make some experiments in this area (uniform path fallback was added to 2015 macros used on 2018 edition in #56053 (comment)).

UPDATE: The last commit also stabilizes the feature `uniform_paths`.

Closes #53130
Closes #55618
Closes #56326
Closes #56398
Closes #56417
Closes #56821
Closes #57252
Closes #57422
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name resolution
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants