Miscellaneous refactors around how lints and typeck interact #39434
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@bors r+ |
|
📌 Commit f3aa085 has been approved by |
Otherwise they are a "hidden output"
It is pretty suspect to insert an entry twice.
The previous way was not friendly to incremental compilation. The new plan is to compute, for each body, a set of trait imports used in that body (slightly subtle: for a closure, we assign the trait imports to the enclosing fn). Then we walk all bodies and union these sets. The reason we do this is that we can save the individual sets in the incremental state, and then recompute only those sets that are needed. Before we were planning to save only the final union, but in that case if some components are invalidated we have to recompute *all* of them since we don't have enough information to "partly" invalidate a result. In truth, this set probably ought to be part of the `TypeckTables`; however, I opted not to do that because I don't want to have to save/restore the entire tables in the incremental state yet (since it contains a lot of `NodeId` references, and removing those is a significant refactoring).
nikomatsakis
force-pushed
the
incr-comp-skip-typeck-2
branch
from
f3aa085
to
4b5613c
Compare
|
@eddyb I reworked this branch substantially, so you probably want to take another look. In particular, I did the following
|
|
@nikomatsakis r=me but some of the incremental tests are failing (see Travis). |
|
@eddyb ah, strange, I thought they passed locally, but ... I'll figure it out. /me grumpy. |
|
@bors r=eddyb |
|
📌 Commit 2fc1586 has been approved by |
bors
added a commit
that referenced
this pull request
Feb 4, 2017
Miscellaneous refactors around how lints and typeck interact
This is preparation for making incr. comp. skip typeck. The main gist of is trying to rationalize the outputs from typeck that are not part of tables:
- one bit of output is the `used_trait_imports` set, which becomes something we track for dependencies
- the other big of output are various lints; we used to store these into a table on sess, but this work stores them into the`TypeckTables`, and then makes the lint pass consult that
- I think it probably makes sense to handle errors similarly, eventually, but that's not necessary now
r? @eddyb
Fixes #39495
|
☀️ Test successful - status-appveyor, status-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is preparation for making incr. comp. skip typeck. The main gist of is trying to rationalize the outputs from typeck that are not part of tables:
used_trait_importsset, which becomes something we track for dependenciesTypeckTables, and then makes the lint pass consult thatr? @eddyb
Fixes #39495