Type privacy polishing #46083
Type privacy polishing #46083
Conversation
|
@bors try |
|
⌛ Trying commit 49c642c5fcda8a55fe0957b28298c3b602ced55d with merge 5ce31c1635dfa52f6071a39712fd3d50c57a5767... |
kennytm
added
S-waiting-on-review
|
☀️ Test successful - status-travis |
|
ping @aidanhs @Mark-Simulacrum |
|
Crater run started |
|
Ping @aidanhs -- has crater finished? |
|
Unfortunately the build failed because the disk filled up (I'm not clear why, but it did), so I've restarted the run - it'll be done in another few days. Sorry! |
|
Hi @petrochenkov (crater requester), @eddyb (reviewer)! Crater results are at: http://cargobomb-reports.s3.amazonaws.com/pr-46083/index.html. 'Blacklisted' crates (spurious failures etc) can be found here. If you see any spurious failures not on the list, please make a PR against that file. (interested observers: Crater is a tool for testing the impact of changes on the crates.io ecosystem. You can find out more at the repo if you're interested) |
|
Three legit regressions:
I'll send PRs. |
petrochenkov
force-pushed
the
morepriv
branch
from
49c642c to
679165c
Compare
|
Rebased and sent PRs to affected crates. |
petrochenkov
added
S-waiting-on-review
shepmaster
added
the
T-compiler
|
Ping from triage! It's been over 7 days since we heard from reviewer @eddyb. Please assign a new reviewer @rust-lang/compiler. |
|
@shepmaster Oh, sorry, IMO this is good to go, I just wanted an extra confirmation. |
|
Ping @nikomatsakis for review! (also on IRC) |
|
☔ The latest upstream changes (presumably #46641) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Argh my apologies @petrochenkov |
|
@bors r+ |
|
📌 Commit 679165c has been approved by |
|
@bors r- well, r=me, unmergeable. |
according to RFC 2145. Fix a silly label message.
petrochenkov
force-pushed
the
morepriv
branch
from
679165c to
c6209a3
Compare
|
@bors r=nikomatsakis |
|
📌 Commit c6209a3 has been approved by |
Type privacy polishing Various preparations before implementing rust-lang/rfcs#2145 containing final minor breaking changes (mostly for unstable code or code using `allow(private_in_public)`). (Continuation of #42125, #44633 and #41332.) It would be good to run crater on this. r? @eddyb
|
☀️ Test successful - status-appveyor, status-travis |
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.
Various preparations before implementing rust-lang/rfcs#2145 containing final minor breaking changes (mostly for unstable code or code using
allow(private_in_public)).(Continuation of #42125, #44633 and #41332.)
It would be good to run crater on this.
r? @eddyb