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

extern crate epoch lint for Path Clarity RFC (2126) #48719

Closed
Manishearth opened this issue Mar 4, 2018 · 13 comments · Fixed by #50260
Closed

extern crate epoch lint for Path Clarity RFC (2126) #48719

Manishearth opened this issue Mar 4, 2018 · 13 comments · Fixed by #50260
Assignees
Labels
S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. WG-epoch Working group: Epoch (2018) management

Comments

@Manishearth
Copy link
Member

Manishearth commented Mar 4, 2018

We need to add an epoch lint for RFC 2126

It will lint extern crate foobar;, suggesting removal in root mods, and replacement with use foobar; in non-root mods.

This is blocked on the ability to elide extern crate in the first place.

@Manishearth Manishearth added the S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. label Mar 4, 2018
@Manishearth Manishearth self-assigned this Mar 4, 2018
@est31
Copy link
Member

est31 commented Mar 4, 2018

It is also blocked on a feature to force linkage of a crate, see this comment and the discussion afterwards: #44660 (comment)

@Manishearth Manishearth added the WG-epoch Working group: Epoch (2018) management label Mar 6, 2018
@Manishearth
Copy link
Member Author

cc @cramertj

@golddranks
Copy link
Contributor

golddranks commented Apr 19, 2018

I think the lint should be by default off in cases with macro_use, such as:

#[macro_use] extern crate slog;

This is because of the ergonomics problems with macro_rules! macros and the new macro import system, expressed here: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252/18?u=golddranks

It's bewildering for the migrating users if a lint tells them not to use the extern crate syntax, but then finding out that many of the macros out there have downright bad ergonomics with the use import syntax.

(For clarification: I think this is an undesirable state of affairs, and we should be linting against all extern crates, but if we do that, the ergonomics problem with the macro import should be fixed somehow.)

@alexreg
Copy link
Contributor

alexreg commented Apr 19, 2018

I don't think we want extern crate at all, really. If we want to import macros, we should have another means of doing it. Otherwise we have an inconsistency. So yes, I think I agree with your last paragraph above all, @golddranks.

@est31
Copy link
Member

est31 commented Apr 20, 2018

@golddranks @alexreg I've discussed this a bit in the tracking issue for the macros import system: #35896 (comment)

@golddranks
Copy link
Contributor

@est31 Thanks, you expressed the exact concern I had in a concise way.

@Manishearth
Copy link
Member Author

Another thing this needs to lint is unlisted crates that are included in Cargo.toml that clash with existing modules.

I'm not quite sure on what the story needs to be here cc @rust-lang/lang

@est31
Copy link
Member

est31 commented Apr 21, 2018

Does it? I've thought one of the things the path clarity RFC was about was to have separate namespaces for top level modules and extern crates.

@Manishearth
Copy link
Member Author

The current plan has changed a bit so I'm not sure if that is still true.

(If stuff does change it will probably be RFCd again, there's a bit of experimentation going on)

@est31

This comment has been minimized.

@aturon
Copy link
Member

aturon commented Apr 28, 2018

@est31 I've hidden your last comment, which I found hostile and unconstructive.

bors added a commit that referenced this issue May 7, 2018
idiom lints for removing `extern crate`

Based off of #49789

This contains two lints:

 - One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely
 - One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo`

The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly
handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all.

Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`?

r? @nikomatsakis

fixes #48719
bors added a commit that referenced this issue May 8, 2018
idiom lints for removing `extern crate`

Based off of #49789

This contains two lints:

 - One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely
 - One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo`

The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly
handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all.

Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`?

r? @nikomatsakis

fixes #48719
@est31
Copy link
Member

est31 commented May 10, 2018

IDK what @Manishearth has been hearing, but for me, this is the latest state of consensus on that issue, and it seems to have separate namespaces: https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205

@aturon is that the case? You seem unresponsive on IRC that's why I'm using github.

@Manishearth
Copy link
Member Author

That's mostly the latest state of consensus, yeah. Some tweaks have been made iirc.

Everything has been implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. WG-epoch Working group: Epoch (2018) management
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants