make most maps private #41368

nikomatsakis · 2017-04-18T14:57:30Z

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

eddyb · 2017-04-18T16:11:04Z

src/librustc/ty/maps.rs

    span: Span,
-    cycle: RefMut<'a, [(Span, Query<'tcx>)]>,
+    cycle: Vec<(Span, Query<'tcx>)>,


Why? This is going to clone all over the place now in early coherence and whatnot.

I wasn't sure about this change. Coherence generates (and recovers from) cycles regularly?

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).

(Maybe we can downgrade to a read-only borrow or something...?)

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).

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).

I guess if I added such a method I could use it for typeck_tables too (in save analysis).

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.

Still unaddressed.

eddyb · 2017-04-18T16:13:32Z

src/librustc/ty/mod.rs

+            .expect("not an associated item")
+    }
+
+    pub fn opt_associated_item(self, def_id: DefId) -> Option<AssociatedItem> {


Can't we avoid introducing queries like these? i.e. actually check what kind of DefId you have before calling associated_item.

Yeah, probably, is there a non-tedious way to do this that works across crates?

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()".

You can check the HIR map (TraitItem and ImplItem) for local and describe_def for external.

eddyb · 2017-04-18T16:25:08Z

src/librustc_save_analysis/dump_visitor.rs

-            }
-            None => f(self),
-        }
+        let tables = ty::queries::typeck_tables::get(self.tcx, DUMMY_SP, item_def_id);


This is actually @nrc's attempt at error recovery, heh.

I was wondering about that

Do you think this will work?

Oh, since it's on-demand... let me find where this was added maybe @nrc provided an example.

lolsob there's no example in #39285

Now that I think more about it... it will probably work anyway.

bors · 2017-04-18T21:26:54Z

☔ The latest upstream changes (presumably #41373) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2017-04-25T16:23:12Z

@eddyb I think I addressed all of your requests; I also rebased atop your branch.

eddyb · 2017-04-25T16:29:33Z

@bors r+

bors · 2017-04-25T16:29:34Z

📌 Commit 41ad2d2 has been approved by eddyb

nikomatsakis · 2017-04-25T16:29:41Z

@bors r=eddyb

bors · 2017-04-25T16:29:42Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: Run tests for the cargo submodule in tree #41362

bors · 2017-04-25T16:29:42Z

📌 Commit 41ad2d2 has been approved by eddyb

bors · 2017-04-26T02:32:09Z

☔ The latest upstream changes (presumably #41332) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2017-04-26T16:42:19Z

@bors r=eddyb

bors · 2017-04-26T16:42:20Z

📌 Commit 054642e has been approved by eddyb

@eddyb

…-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 · 2017-04-27T05:44:19Z

⌛ Testing commit 054642e with merge 569d203...

bors · 2017-04-27T06:18:39Z

💔 Test failed - status-appveyor

aidanhs · 2017-04-27T09:03:09Z

@bors retry

Appveyor network issues https://appveyor.statuspage.io/incidents/06gzq846jl9x

bors · 2017-04-27T10:05:00Z

⌛ Testing commit 054642e with merge 86f699c...

bors · 2017-04-27T10:32:12Z

💔 Test failed - status-travis

@eddyb

…-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 · 2017-04-28T04:29:14Z

This hit the same failure on dist-aarch64-linux that @arielb1 mentioned earlier

@bors r-

https://travis-ci.org/rust-lang/rust/jobs/226667988

bors · 2017-04-28T07:30:33Z

☔ 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.)

And 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.

nikomatsakis · 2017-04-28T15:59:39Z

@bors r=eddyb

bors · 2017-04-28T15:59:40Z

📌 Commit d7d3f19 has been approved by eddyb

bors · 2017-04-28T16:07:32Z

⌛ Testing commit d7d3f19 with merge 543f365...

bors · 2017-04-28T16:10:06Z

💔 Test failed - status-appveyor

TimNN · 2017-04-28T16:13:19Z

@bors retry

Tracking issue for spurious network failures on bots #40474

nikomatsakis · 2017-04-28T18:29:13Z

@bors rollup-

bors · 2017-04-28T18:53:31Z

⌛ Testing commit d7d3f19 with merge 128aa26...

@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 · 2017-04-28T21:38:23Z

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 128aa26 to master...

rust-highfive assigned eddyb Apr 18, 2017

eddyb reviewed Apr 18, 2017

View reviewed changes

aidanhs added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 19, 2017

nikomatsakis force-pushed the incr-comp-dep-tracking-map branch 2 times, most recently from 0f3c43e to 854a5dd Compare April 25, 2017 16:22

nikomatsakis force-pushed the incr-comp-dep-tracking-map branch 2 times, most recently from e2d55be to 41ad2d2 Compare April 25, 2017 16:29

nikomatsakis force-pushed the incr-comp-dep-tracking-map branch from 41ad2d2 to 054642e Compare April 26, 2017 16:42

frewsxcv mentioned this pull request Apr 27, 2017

Rollup of 4 pull requests #41573

Closed

frewsxcv mentioned this pull request Apr 28, 2017

Rollup of 4 pull requests #41595

Closed

frewsxcv mentioned this pull request Apr 28, 2017

Rollup of 4 pull requests #41596

Closed

nikomatsakis added 5 commits April 28, 2017 04:15

do not access inherited_impls map directly

f35ff22

do not access associated_item map directly

b11da34

do not access typeck_tables map directly

d26a7a4

allow maps to be made private or public

1ac7eb8

Didn't get around to removing all public access.

make ty and impl_trait_ref private

2cca256

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.)

nikomatsakis force-pushed the incr-comp-dep-tracking-map branch 3 times, most recently from 949f214 to cb618e3 Compare April 28, 2017 13:56

introduce ability to if we have typeck-tables for a given def-id

d7d3f19

And 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.

nikomatsakis force-pushed the incr-comp-dep-tracking-map branch from cb618e3 to d7d3f19 Compare April 28, 2017 14:02

bors merged commit d7d3f19 into rust-lang:master Apr 28, 2017

This was referenced Apr 28, 2017

query for def_span #41593

Merged

Queryify crate metadata #41611

Merged

est31 mentioned this pull request May 2, 2017

Regression in -Z dump-mir=all #41697

Closed

make *most* maps private #41368

make *most* maps private #41368

Conversation

nikomatsakis commented Apr 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis Apr 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Apr 18, 2017

nikomatsakis commented Apr 25, 2017

eddyb commented Apr 25, 2017

bors commented Apr 25, 2017

nikomatsakis commented Apr 25, 2017

bors commented Apr 25, 2017

bors commented Apr 25, 2017

bors commented Apr 26, 2017

nikomatsakis commented Apr 26, 2017

bors commented Apr 26, 2017

bors commented Apr 27, 2017

bors commented Apr 27, 2017

aidanhs commented Apr 27, 2017

bors commented Apr 27, 2017

bors commented Apr 27, 2017

frewsxcv commented Apr 28, 2017

bors commented Apr 28, 2017

nikomatsakis commented Apr 28, 2017

bors commented Apr 28, 2017

bors commented Apr 28, 2017

bors commented Apr 28, 2017

TimNN commented Apr 28, 2017

nikomatsakis commented Apr 28, 2017

bors commented Apr 28, 2017

bors commented Apr 28, 2017

make most maps private #41368

make most maps private #41368

nikomatsakis Apr 18, 2017 •

edited

Loading