[4.0] Fix multi-line string syntax coloring issues #10382
Merged
Conversation
This file contains hidden or 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
added 5 commits
June 19, 2017 13:32
…han start/end line+column and simplify the delta logic This patch changes the syntax map data structure it uses to be offset based rather than line/col based in order to avoid calling getLineAndColumn for the start and end offset of every token. This removes the 30% of time spent in getLineAndColumn for this request in large files (rdar://problem/28965123). The logic for returning the affected range and the token ranges to highlight following an edit also made several assumptions that no longer hold. This patch changes it to compare the syntax maps from before and after the edit, find the first mismtaching tokens from the start and end of the syntax maps and return the tokens in that range (adjusted to line boundaries). This fixes syntax highlighting issues with interpolated multi-line strings (rdar://problem/32148117) and block comments. With the above changes the per-keystroke time spent for syntax highlighting (with sematic info disabled) dropped from ~80ms to just under 50ms for a 12KLOC file.
…gs as strings Also add tests for syntax map deltas when editing multi-line strings
…o new highlighted tokens but are removed ones, and take account of the range of the mismatching token in the previous syntax map We still need to adjust the affected range to the line boundaries and return all tokens on the line when there are no new tokens, as the client will clear all tokens on that line in its copy of the syntax map leaving the other tokens unhighlighted. We also need to extend the affected range to include the ranges of the mismatched tokens from the previous syntaxmap, so their highlighting will be cleared. Also add more comments to better document the new syntax map structure and behaviour.
|
@swift-ci Please test. |
|
PR for master: #10289 |
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.
Explanation: With multi-line strings, edits on one line can make tokens appear/disapear on previous and later lines, which broke assumptions in the existing syntax highlighting logic. This left odd ranges of source unhighlighted or incorrectly highlighted.
Scope: Affects syntax highlighting of source files when users edit multi-line strings.
Radar: rdar://problem/32148117
Risk: Low; The change is limited to syntax highlighting
Testing: Added regression tests and measured the per-keystroke performance in a file with 12K lines of code (it's ~50ms, down from ~80ms).