Report bsp diagnostics in end of incremental cycle #782
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
...instead of reporting at the end of the compilation. This commit intends to report as early as possible in the case where several expensive incremental cycles are triggered. An example of this case can be found in scalameta/metals#438 What this PR does is conceptually simple: 1. At the end of every incremental cycle, process the previous problems that comply with any of these requirements: * Their associated source doesn't exist (bloop clears diagnostics) * Their associated source has already been processed (bloop does nothing as problems have already been reported by `logFull`) * Their associated file was compiled but no problem was registered (bloop appropriately clears diagnostics) * `reportAllPreviousProblems` is true. This happens in the first compilation of a target via BSP and it's only done at the end of the compilation, so in every intermediate incremental cycle it's false. 2. Every problem that is processed will not be processed in the future. This bit of logic avoids repeating the handling of reported problems. This change is already tested by our previous infrastructure.
jvican
added
enhancement
build server
jvican
added a commit
that referenced
this pull request
Jan 10, 2019
BSP requires that bloop clears problems that were present in previous compiler iterations manually. Previously, Bloop would meet this contract by clearing problems from previous compiler runs at the end of a successful incremental cycle. For every incremental cycle, bloop would go through the problems and clear those that were affected by changes occurred during that cycle. You can see more information in this pull request: #782 However, this approach was slower than desired and required that we successfully finished an incremental compiler cycle before *starting* to clean some diagnostics in the recompiled files. Instead, this pull request takes a different approach to this problem. We clear diagnostics as soon as we know they are safe to be cleared. For example, if in a previous compiler run typer emitted an error, we have bloop record that a diagnostic happened during that phase and, in subsequent compiler runs, we clear the diagnostic as soon as we've passed typer for the source file that contained the error. That is, we clear diagnostics right after the phase that generated them succeeded. If a diagnostic could not be mapped to a phase, we fallback to the previous behavior: we will clear it in `reportRemainingProblems` right after every incremental cycle.
jvican
added a commit
that referenced
this pull request
Jan 10, 2019
BSP requires that bloop clears problems that were present in previous compiler iterations manually. Previously, Bloop would meet this contract by clearing problems from previous compiler runs at the end of a successful incremental cycle. For every incremental cycle, bloop would go through the problems and clear those that were affected by changes occurred during that cycle. You can see more information in this pull request: #782 However, this approach was slower than desired and required that we successfully finished an incremental compiler cycle before *starting* to clean some diagnostics in the recompiled files. Instead, this pull request takes a different approach to this problem. We clear diagnostics as soon as we know they are safe to be cleared. For example, if in a previous compiler run typer emitted an error, we have bloop record that a diagnostic happened during that phase and, in subsequent compiler runs, we clear the diagnostic as soon as we've passed typer for the source file that contained the error. That is, we clear diagnostics right after the phase that generated them succeeded. If a diagnostic could not be mapped to a phase, we fallback to the previous behavior: we will clear it in `reportRemainingProblems` right after every incremental cycle.
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.
...instead of reporting at the end of the compilation.
This commit intends to report as early as possible in the case where
several expensive incremental cycles are triggered. An example of this
case can be found in scalameta/metals#438
What this PR does is conceptually simple:
that comply with any of these requirements:
nothing as problems have already been reported by
logFull)(bloop appropriately clears diagnostics)
reportAllPreviousProblemsis true. This happens in the firstcompilation of a target via BSP and it's only done at the end of the
compilation, so in every intermediate incremental cycle it's false.
This bit of logic avoids repeating the handling of reported problems.
This change is already tested by our previous infrastructure.