Uh oh!
There was an error while loading. Please reload this page.
make *most* maps private - #41368
Conversation
There was a problem hiding this comment.
Why? This is going to clone all over the place now in early coherence and whatnot.
There was a problem hiding this comment.
I wasn't sure about this change. Coherence generates (and recovers from) cycles regularly?
There was a problem hiding this comment.
The reason for it was that, when we call report_cycle, we hold the borrow-mut lock, which then messes up my attempts to use try_get from within the pretty-printing code (it fails to acquire the RefCell lock).
There was a problem hiding this comment.
(Maybe we can downgrade to a read-only borrow or something...?)
There was a problem hiding this comment.
We don't have downgrading, but queries need mutable anyway so you wouldn't get anything.
Why do you want to query from the printing code? You could clone the stack and drop the RefMut when reporting a cycle error if you want, that's fine (since reporting itself costs anyway).
There was a problem hiding this comment.
Why do you want to query from the printing code?
I don't necessarily want that. But the printing code currently pokes at the query's internal maps to find out if trait_ref and ty are filled out for particular def-ids (or something like that). I guess I could add an accessor for reading the current state of the query that you are really, really not supposed to use (because it lets you observe things you shouldn't be able to observe), just for use in printing things out -- but really it seems like it might make sense for printing things out to run bits of type-check that may not have run, if it is needed to pretty-print better (i.e., if we were in a totally on-demand scenario, and some error arose, it seems plausible it might need to pretty print something that hasn't yet been "collected"--- well, maybe that would never happen in practice).
There was a problem hiding this comment.
I guess if I added such a method I could use it for typeck_tables too (in save analysis).
There was a problem hiding this comment.
Ohhh, you were talking about item_path_str, now I know exactly what you're talking about.
Yeah just do the stack.to_vec(); drop(stack) thing when reporting.
There was a problem hiding this comment.
Can't we avoid introducing queries like these? i.e. actually check what kind of DefId you have before calling associated_item.
There was a problem hiding this comment.
Yeah, probably, is there a non-tedious way to do this that works across crates?
There was a problem hiding this comment.
The method would probably stay the same, I suppose, but it would be wrapped in code like "check type of def_id then call associated_item()".
There was a problem hiding this comment.
You can check the HIR map (TraitItem and ImplItem) for local and describe_def for external.
There was a problem hiding this comment.
This is actually @nrc's attempt at error recovery, heh.
There was a problem hiding this comment.
I was wondering about that
There was a problem hiding this comment.
Do you think this will work?
There was a problem hiding this comment.
Oh, since it's on-demand... let me find where this was added maybe @nrc provided an example.
There was a problem hiding this comment.
Now that I think more about it... it will probably work anyway.
bors
commented
Apr 18, 2017
☔ The latest upstream changes (presumably #41373) made this pull request unmergeable. Please resolve the merge conflicts. |
0f3c43e to
854a5ddComparenikomatsakis
commented
Apr 25, 2017
@eddyb I think I addressed all of your requests; I also rebased atop your branch. |
e2d55be to
41ad2d2Compareeddyb
commented
Apr 25, 2017
@bors r+ |
bors
commented
Apr 25, 2017
📌 Commit 41ad2d2 has been approved by |
nikomatsakis
commented
Apr 25, 2017
@bors r=eddyb |
bors
commented
Apr 25, 2017
💡 This pull request was already approved, no need to approve it again.
|
bors
commented
Apr 25, 2017
📌 Commit 41ad2d2 has been approved by |
bors
commented
Apr 26, 2017
☔ The latest upstream changes (presumably #41332) made this pull request unmergeable. Please resolve the merge conflicts. |
41ad2d2 to
054642eComparenikomatsakis
commented
Apr 26, 2017
@bors r=eddyb |
bors
commented
Apr 26, 2017
📌 Commit 054642e has been approved by |
…-map, r=eddyb make *most* maps private Currently we access the `DepTrackingMap` fields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary. r? @eddyb
bors
commented
Apr 27, 2017
⌛ Testing commit 054642e with merge 569d203... |
bors
commented
Apr 27, 2017
💔 Test failed - status-appveyor |
aidanhs
commented
Apr 27, 2017
@bors retry Appveyor network issues https://appveyor.statuspage.io/incidents/06gzq846jl9x |
bors
commented
Apr 27, 2017
⌛ Testing commit 054642e with merge 86f699c... |
bors
commented
Apr 27, 2017
💔 Test failed - status-travis |
…-map, r=eddyb make *most* maps private Currently we access the `DepTrackingMap` fields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary. r? @eddyb
frewsxcv
commented
Apr 28, 2017
bors
commented
Apr 28, 2017
☔ The latest upstream changes (presumably #41598) made this pull request unmergeable. Please resolve the merge conflicts. |
Didn't get around to removing all public access.
This requires copying out the cycle error to avoid a cyclic borrow. Is this a problem? Are there paths where we expect cycles to arise and not result in errors? (In such cases, we could add a faster way to test for cycle.)
949f214 to
cb618e3CompareAnd use this in save-analysis, which used to read the map directly. This is an attempt to sidestep the failure occuring on homu that I cannot reproduce.
cb618e3 to
d7d3f19Comparenikomatsakis
commented
Apr 28, 2017
@bors r=eddyb |
bors
commented
Apr 28, 2017
📌 Commit d7d3f19 has been approved by |
bors
commented
Apr 28, 2017
⌛ Testing commit d7d3f19 with merge 543f365... |
bors
commented
Apr 28, 2017
💔 Test failed - status-appveyor |
TimNN
commented
Apr 28, 2017
nikomatsakis
commented
Apr 28, 2017
@bors rollup- |
bors
commented
Apr 28, 2017
make *most* maps private Currently we access the `DepTrackingMap` fields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary. r? @eddyb
bors
commented
Apr 28, 2017
☀️ Test successful - status-appveyor, status-travis |
Currently we access the
DepTrackingMapfields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary.r? @eddyb