On demandify reachability

[cramertj]

cc #40746

I tried following this guidance from #40746:

The following tasks currently execute before a tcx is built, but they could be easily converted into queries that are requested after tcx is built. The main reason they are the way they are was to avoid a gratuitious refcell (but using the refcell map seems fine)...

but the result of moving region_maps out of TyCtxt and into a query caused a lot of churn, and seems like it could potentially result in a rather large performance hit, since it means a dep-graph lookup on every use of region_maps (rather than just a field access). Possibly TyCtxt could store a RefCell<Option<RegionMap>> internally and use that to prevent repeat lookups, but that feels like it's duplicating the work of the dep-graph. @nikomatsakis What did you have in mind for this?

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[cramertj]

r? @nikomatsakis

[nikomatsakis]

Regarding the region-maps:

• First, we should measure the performance. It may or may not be significant.

• Second, it seems like it is becoming quite common to have things that are effectively "lazilly computed globals". Right now we are handling those uniformly (with the cache key being a crate number) but maybe it's worth treating them as an (encapsulated) Option field.

• Third, I expect that some amount of local caching (i.e., if we access region_maps() many times in a loop, we can store it into a local variable) would solve the problem.

Certainly we should solve this problem, because I think this is roughly the pattern we want going forward. But I think it won't be hard to solve.

[eddyb]

IMO we would have all the maps per-crate, and HashMap<(), V> should be quite efficient - even if it's not, we could use specialization.

[nikomatsakis]

@eddyb seems reasonable, yes

[cramertj]

@eddyb Should I take that to mean that I should leave it as-is for now (module fixing the tidy check)? Also, is there interest in having queries include a get_ref function or similar to access the result, rather than having to wrap in an Rc?

[bors]

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

[nikomatsakis]

@cramertj Rc is better, I think, because it avoids refcell issues, and it's simpler to have all of the queries pass ownership.

[bors]

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

[cramertj]

Removed region-mapping in favor of #41057

[nikomatsakis]

@bors r+

[bors]

📌 Commit aab2cca has been approved by nikomatsakis

[bors]

⌛ Testing commit aab2cca with merge 408c882...

[bors]

💔 Test failed - status-appveyor

[alexcrichton]

@bors: retry * ar.exe error #40546

…

On Thu, Apr 6, 2017 at 1:37 PM, bors ***@***.***> wrote: 💔 Test failed - status-appveyor <https://ci.appveyor.com/project/rust-lang/rust/build/1.0.2804> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#40873 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD95ECs5QAye9DVa2FVWNENcAD47mVUks5rtT7zgaJpZM4MrNru> .

[bors]

⌛ Testing commit aab2cca with merge 4c59c92...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 4c59c92 to master...

[aidanhs]

This (spuriously) hung halfway through one of the OSX tests (guess which one), possibly related to #40571, cc @alexcrichton. It then recovered after about 45mins and continued.

[alexcrichton]

@aidanhs the full logs for that build are super weird. I wonder if there's a few travis bugs in play here. I'm seeing no discontinuities in our logging (which all have timestamps), but I'm seeing stuff like:

[00:56:40]     Finished release [optimized] target(s) in 0.1 secs

[00:32:05]    Compiling rustc_llvm v0.0.0 (file:///Users/travis/build/rust-lang/rust/src/librustc_llvm)

[00:56:40] Copying stage0 std from stage0 (i686-apple-darwin -> i686-apple-darwin / i686-apple-darwin)

[00:32:11]    Compiling syntax_pos v0.0.0 (file:///Users/travis/build/rust-lang/rust/src/libsyntax_pos)

[00:56:41] Building stage0 test artifacts (i686-apple-darwin -> i686-apple-darwin)

[00:56:41]     Finished release [optimized] target(s) in 0.0 secs

[00:32:17]    Compiling rustc_errors v0.0.0 (file:///Users/travis/build/rust-lang/rust/src/librustc_errors)

No idea why it's jumping back and forth...