transition borrowck to visit all **bodies** and not item-likes#39927
transition borrowck to visit all **bodies** and not item-likes#39927bors merged 16 commits intorust-lang:masterfrom
Conversation
|
@bors r+ |
|
📌 Commit 4ca1f02 has been approved by |
d38b5f7 to
d83d83e
Compare
|
@bors r=eddyb |
|
📌 Commit d83d83e has been approved by |
|
@bors r- |
aabf3df to
7770e9a
Compare
| } | ||
|
|
||
| fn is_body_owner(self, node_id: NodeId) -> bool { | ||
| fn associated_body(self) -> Option<BodyId> { |
There was a problem hiding this comment.
I have at least two, if not three, reimplementations of this, seems so obvious in retrospect!
src/librustc/dep_graph/visit.rs
Outdated
| where C: Fn(/* body_owner */ DefId, /* body id */ hir::BodyId), | ||
| { | ||
| // NB: we use a visitor here rather than walking the keys of the | ||
| // hashmap so as to ensure we visit the bodies "in order". |
There was a problem hiding this comment.
Well, first off, the hashmap should maybe be replaced with a BTreeMap.
But also, you don't want HIR lowering node IDs to matter... what if it was keyed by the owner's DefIndex?
There was a problem hiding this comment.
Either way, BTreeMap might be enough to fix your problem here.
There was a problem hiding this comment.
I tried that first, but it still came in what seemed to me to be a surprising order in some cases. But maybe I'll switch it back to a btree-map and just adjust the reference files.
Still, I was thinking that longer term it might be a better idea to have some vector stored in the crate of the preferred "visit order".
There was a problem hiding this comment.
I agree, and I'd be fine sorting by Span or something (so the HIR visit order doesn't matter).
|
I did a crater run of an earlier draft of this branch. Result: 4 false positives, but no regressions found. |
|
@bors r=eddyb |
|
📌 Commit fed58f3 has been approved by |
|
A revised crater run revealed only timeouts (7 of them). |
|
@bors r=eddyb |
|
📌 Commit fed58f3 has been approved by |
…k-2, r=eddyb transition borrowck to visit all **bodies** and not item-likes This is a better structure for incremental compilation and also more compatible with the eventual borrowck mir. It also fixes rust-lang#38520 as a drive-by fix. r? @eddyb
Rollup of 28 pull requests - Successful merges: #39859, #39864, #39888, #39903, #39905, #39914, #39945, #39950, #39953, #39961, #39980, #39988, #39993, #39995, #40019, #40020, #40022, #40024, #40025, #40026, #40027, #40031, #40035, #40037, #40038, #40064, #40069, #40086 - Failed merges: #39927, #40008, #40047
| } | ||
| } | ||
|
|
||
| impl<'a, 'tcx> ItemLikeVisitor<'tcx> for CheckItemBodiesVisitor<'a, 'tcx> { |
There was a problem hiding this comment.
You should also remove the item_tables queries from CheckItemTypesVisitor (the rest of which belongs in collect IMO).
|
@eddyb see latest commit, which I think is what you meant |
|
@bors r=eddyb |
|
📌 Commit f704ef5 has been approved by |
|
⌛ Testing commit f704ef5 with merge a1f6823... |
|
💔 Test failed - status-appveyor |
|
@bors: retry
* network error
…On Tue, Feb 28, 2017 at 4:23 PM, bors ***@***.***> wrote:
💔 Test failed - status-appveyor
<https://ci.appveyor.com/project/rust-lang/rust/build/1.0.2169>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#39927 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95PU6_DB2HIhAGOfUr1aHORFhoZMmks5rhJ5KgaJpZM4MFGkh>
.
|
|
@alexcrichton thanks for staying on top of these ... almost every time I find one, you've already tagged it... |
|
⌛ Testing commit f704ef5 with merge 53f60d5... |
|
💔 Test failed - status-appveyor |
|
actual failure: |
|
@eddyb r? the last commit |
|
@bors r+ |
|
📌 Commit d572aa2 has been approved by |
|
⌛ Testing commit d572aa2 with merge 06c63f6... |
|
☀️ Test successful - status-appveyor, status-travis |
| @@ -180,23 +181,6 @@ impl<'a, 'gcx: 'tcx, 'tcx> MutVisitor<'tcx> for GlobalizeMir<'a, 'gcx> { | |||
| /////////////////////////////////////////////////////////////////////////// | |||
| // BuildMir -- walks a crate, looking for fn items and methods to build MIR from | |||
There was a problem hiding this comment.
It seems this comment refers to the removed BuildMir struct.
Should it also be removed?
This is a better structure for incremental compilation and also more compatible with the eventual borrowck mir. It also fixes #38520 as a drive-by fix.
r? @eddyb