Create Incremental Parser.md#82019
Conversation
Co-authored-by: Joseph Musser <me@jnm2.com>
Co-authored-by: Joseph Musser <me@jnm2.com>
| In most cases, reparsing M1 will produce the same skipped tokens as before. However, it's possible | ||
| that the edit in M2 could affect M1's parse due to lookahead. For example, if M1's error was caused | ||
| by something that the edit in M2 somehow resolved, the reparse of M1 might produce a different | ||
| (possibly valid) tree. |
There was a problem hiding this comment.
So if there are parse errors that result in neither skipped nor missing tokens, these constraints don't apply and the subtree with the error will be reused? But can't it also be affected by lookahead? (In fact, cannot any parsing, even successful one, be affected by lookahead like this?)
There was a problem hiding this comment.
I'll adjust. If it has any diagnostics, it is not reused. It's just that skipped/missing are the major causes of diagnostics. I've written previously that they should be the only causes in the parser. But we're not currently there.
There was a problem hiding this comment.
I'll adjust. If it has any diagnostics, it is not reused. It's just that skipped/missing are the major causes of diagnostics. I've written previously that they should be the only causes in the parser. But we're not currently there.
There was a problem hiding this comment.
I see. And for non-erroneous parsing, I guess the incremental parsing logic just assumes that the underlying parsing logic won't be affected by lookahead across the reusable blocks?
There was a problem hiding this comment.
guess the incremental parsing logic just assumes that the underlying parsing logic won't be affected by lookahead across the reusable blocks?
Correct. We know that this is true by construction (currently). And we have no language constructs we're interested in that would change this.
| Generated files (source generators, T4 templates, etc.) are not a concern for incremental parsing | ||
| performance. Users don't edit generated files in real time, so we won't be receiving incremental | ||
| edits for them. Full parses of generated files are acceptable since they happen infrequently | ||
| (typically only when the generator runs). |
There was a problem hiding this comment.
Some probably do (or will) run on every keystroke, like razor, right?
There was a problem hiding this comment.
Yes. But as mentioned, razor does not produce edits. So we will full parse. If we wanted incremental there we'd need razor to change how it generates the new docs.
This may be an area that needs attention in the future. But it's currently out of scope with all the rest of the things razor needs to address first :-)
No description provided.