-
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
privacy: Use common DefId
visiting infrastructure for all privacy visitors
#56878
Conversation
r? @arielb1 |
I'll take a more detailed look tomorrow. |
So, I started to factor out the common "visit all def-ids in a type" functionality and it turned out a bit trickier than expected, I'll update the PR today hopefully. |
0a870ab
to
829bfbf
Compare
829bfbf
to
fb1ef41
Compare
This comment has been minimized.
This comment has been minimized.
fb1ef41
to
66265df
Compare
This comment has been minimized.
This comment has been minimized.
66265df
to
b1b8db2
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
b1b8db2
to
4c460ae
Compare
DefId
visiting infra for all privacy visitors
DefId
visiting infra for all privacy visitorsDefId
visiting infrastructure for all privacy visitors
4c460ae
to
e7f3a59
Compare
The PR is completely rewritten, see the new description. cc people who reviewed previous PRs in this area (#46083 and friends) |
let mut me = self; | ||
(&mut me).read_to_end(buf) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an unused function newly detected due to improved reachability analysis (which is based on privacy data).
Updated. |
/// The idea is to visit "all components of a type", as documented in | ||
/// https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md#how-to-determine-visibility-of-a-type | ||
/// Default type visitor (`TypeVisitor`) does most of the job, but it has some shortcomings. | ||
/// First, it doesn't have overridable `fn visit_trait_ref`, so we have to catch trait def-ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it would be good to support this in TypeVisitor
itself, but I'm not sure this PR is the best place for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
r=me with over-approximation comment |
Say "trait" instead of "type" in diagnostics for `dyn Trait`
16dfa1e
to
60d1fa7
Compare
@bors r=arielb1 |
📌 Commit 60d1fa7 has been approved by |
privacy: Use common `DefId` visiting infrastructure for all privacy visitors One repeating pattern in privacy checking is going through a type, visiting all `DefId`s inside it and doing something with them. This is the case because visibilities and reachabilities are attached to `DefId`s. Previously various privacy visitors visited types slightly differently using their own methods, with most recently written `TypePrivacyVisitor` being the "gold standard". This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported. This PR does something that I wanted to do since #32674 (comment) - factoring out the common visiting logic! Now all the common logic is contained in `struct DefIdVisitorSkeleton`, with specific privacy visitors deciding only what to do with visited `DefId`s (via `trait DefIdVisitor`). A bunch of cleanups is also applied in the process. This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in #46083 and previous PRs, so I'm relatively sure in the refactoring correctness. Fixes #56837 (comment) in particular. Also this will help with implementing #48054.
☀️ Test successful - status-appveyor, status-travis |
@@ -709,6 +709,9 @@ define_print! { | |||
|
|||
define_print! { | |||
('tcx) ty::ExistentialTraitRef<'tcx>, (self, f, cx) { | |||
display { | |||
cx.parameterized(f, self.substs, self.def_id, &[]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wrong. The substs
are missing the Self
type, which is why the debug {...}
implementation below does through all of that trouble of creating a TraitRef
.
I think the correct fix is moving the code from debug {...}
to display {...}
and changing debug {...}
to contain just self.print_display(f, cx)
.
privacy: Fix private-in-public check for existential types Fixes rust-lang#53546 (regression from rust-lang#56878) r? @arielb1
privacy: Fix private-in-public check for existential types Fixes rust-lang#53546 (regression from rust-lang#56878) r? @arielb1
One repeating pattern in privacy checking is going through a type, visiting all
DefId
s inside it and doing something with them.This is the case because visibilities and reachabilities are attached to
DefId
s.Previously various privacy visitors visited types slightly differently using their own methods, with most recently written
TypePrivacyVisitor
being the "gold standard".This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported.
This PR does something that I wanted to do since #32674 (comment) - factoring out the common visiting logic!
Now all the common logic is contained in
struct DefIdVisitorSkeleton
, with specific privacy visitors deciding only what to do with visitedDefId
s (viatrait DefIdVisitor
).A bunch of cleanups is also applied in the process.
This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in #46083 and previous PRs, so I'm relatively sure in the refactoring correctness.
Fixes #56837 (comment) in particular.
Also this will help with implementing #48054.