incr.comp.: Implement "eval-always" queries

[michaelwoerister]

For each query invocation the query system will track which other queries have been invoked by the former. We collect this data in the DepGraph and use it to find which queries need to be re-executed in a subsequent compilation session. However, there are some queries (like collect_and_partition_translation_items for example) that access pretty much everything in the current crate and therefore:

• will introduce a lot of dependency edges in the graph, while at the same time
• are very likely to be re-executed if there is even a small change to the code base.

We can take advantage of this domain knowledge by introducing so-called "eval-always" queries. This is a special kind of query where we opt into super coarse-grained dependency tracking: Instead of recording each individual read-edge, we just record a single read to DepNode::Krate. This has the effect that any change will make this query be re-executed.

Note that it is not entirely clear how much of a performance win this can provide but it's certainly interesting to test out.

There are a few steps to implementing this:

• Add a new kind of task in https://github.com/rust-lang/rust/blob/master/src/librustc/dep_graph/graph.rs that behaves like OpenTask::Ignore in fn read_index but, upon closing, registers a read to DepNode::Krate.
• Make the new kind of task available to the outside as DepGraph::with_eval_always_task().
• Allow for declaring a DepKind/DepNode as "eval_always", the same way it is possible to mark them as anon or input.
• Make fn try_get_with() in https://github.com/rust-lang/rust/blob/master/src/librustc/ty/maps/plumbing.rs check of the DepNode being "eval_always" and if true, execute compute_result within DepGraph::with_eval_always_task() (very similar to the anon case)
• Switch the following queries to being "eval_always":
  • collect_and_partition_translation_items
  • lint_levels
  • privacy_access_levels (and remove with_ignore from librustc_privacy::check_crate)

Feel free to come up with a better name for "eval-always". It's really not a good name :)

cc @wesleywiser @nikomatsakis

[nikomatsakis]

Some other queries for which eval-always might be useful:

• crate_variances
• variances_of
• crate_inherent_impls
• inherent_impls
• crate_inherent_impls_overlap_check

[wesleywiser]

I'm working on this.

[wesleywiser]

I've pushed up a commit for review that implements the first two parts of this. I'd like to get some feedback on that and make sure I'm doing this correctly before continuing with the rest. I called these queries "untracked queries" instead of "eval always queries". If you like the other name better, I'd be happy to change it.

[michaelwoerister]

Thank you, @wesleywiser! I'll comment on the PR.