-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
It is also blocked on a feature to force linkage of a crate, see this comment and the discussion afterwards: #44660 (comment) |
cc @cramertj |
I think the lint should be by default off in cases with
This is because of the ergonomics problems with It's bewildering for the migrating users if a lint tells them not to use the (For clarification: I think this is an undesirable state of affairs, and we should be linting against all |
I don't think we want |
@golddranks @alexreg I've discussed this a bit in the tracking issue for the macros import system: #35896 (comment) |
@est31 Thanks, you expressed the exact concern I had in a concise way. |
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 |
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. |
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) |
This comment has been minimized.
This comment has been minimized.
@est31 I've hidden your last comment, which I found hostile and unconstructive. |
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
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
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. |
That's mostly the latest state of consensus, yeah. Some tweaks have been made iirc. Everything has been implemented. |
We need to add an epoch lint for RFC 2126
It will lint
extern crate foobar;
, suggesting removal in root mods, and replacement withuse foobar;
in non-root mods.This is blocked on the ability to elide extern crate in the first place.
The text was updated successfully, but these errors were encountered: