-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Suggestion for pub(crate)
not always valid on multiple imports
#50455
Comments
cc @zackmdavis who implemented this I also wish we had a better answer for this lint than chopping up spans, but the current architecture makes this hard (this has been a problem for clippy forever). The problem here is that when we do HIR lowering we split apart But we throw away the AST by the time we have access level info. We can skip this lint for I don't really have ideas for fixing this. |
#50476 proposes not making suggestions for
We could add spans to |
The Higher Intermediate Representation doesn't have spans for visibility keywords, so we were assuming that the first whitespace-delimited token in the item span was the `pub` to be weakened. This doesn't work for brace-grouped `use`s, which get lowered as if they were several individual `use` statements, but with spans that only cover the braced path-segments. Constructing a correct suggestion here presents some challenges—until someone works those out, we can at least protect the dignity of our compiler marking the suggestion for `use` items as potentially incorrect. This resolves rust-lang#50455 (but again, it would be desirable in the future to make a correct suggestion instead of copping out like this).
…gestion, r=Manishearth don't make crazy suggestion for unreachable braced pub-use The Higher Intermediate Representation doesn't have spans for visibility keywords, so we were assuming that the first whitespace-delimited token in the item span was the `pub` to be weakened. This doesn't work for brace-grouped `use`s, which get lowered as if they were several individual `use` statements, but with spans that only cover the braced path-segments. Constructing a correct suggestion here presents some challenges—until someone works those out, we can at least protect the dignity of our compiler by not offering any suggestion at all for `use` items. This resolves rust-lang#50455 (but again, it would be desirable in the future to make a correct suggestion instead of copping out like this). r? @Manishearth
…Manishearth don't make crazy suggestion for unreachable braced pub-use The Higher Intermediate Representation doesn't have spans for visibility keywords, so we were assuming that the first whitespace-delimited token in the item span was the `pub` to be weakened. This doesn't work for brace-grouped `use`s, which get lowered as if they were several individual `use` statements, but with spans that only cover the braced path-segments. Constructing a correct suggestion here presents some challenges—until someone works those out, we can at least protect the dignity of our compiler by not offering any suggestion at all for `use` items. This resolves #50455 (but again, it would be desirable in the future to make a correct suggestion instead of copping out like this). r? @Manishearth
This is a true fix for rust-lang#50455, superior to the mere bandage offered in rust-lang#50476.
…petrochenkov add modifier keyword spans to hir::Visibility; improve unreachable-pub, private-no-mangle lint suggestions #50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix. Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private). ![hir_vis](https://user-images.githubusercontent.com/1076988/42018064-ca830290-7a65-11e8-9c4c-48bc846f861f.png) r? @nrc cc @Manishearth
Given code that looks like:
you get:
which when auto-fixed by
cargo fix
will produce:which fails to compile!
cc @Manishearth
The text was updated successfully, but these errors were encountered: