feat(compiler): Parse and recover on incomplete opening HTML tags#38681
Closed
ayazhafiz wants to merge 4 commits intoangular:masterfrom
Closed
feat(compiler): Parse and recover on incomplete opening HTML tags#38681ayazhafiz wants to merge 4 commits intoangular:masterfrom
ayazhafiz wants to merge 4 commits intoangular:masterfrom
Conversation
kyliau
approved these changes
Sep 2, 2020
ivanwonder
reviewed
Sep 3, 2020
8668491 to
e68d8c3
Compare
atscott
approved these changes
Sep 8, 2020
JoostK
reviewed
Sep 11, 2020
Member
JoostK
left a comment
There was a problem hiding this comment.
Some minor things. In general I think this is a high-risk change, so a global presubmit may be in order.
Let's say we have a code like ```html <div<span>123</span> ``` Currently this gets parsed into a tree with the element tag `div<span`. This has at least two downsides: - An incorrect diagnostic that `</span>` doesn't close an element is emitted. - A consumer of the parse tree using it for editor services is unable to provide correct completions for the opening `<span>` tag. This patch attempts to fix both issues by instead parsing the code into the same tree that would be parsed for `<div></div><span>123</span>`. In particular, we do this by optimistically scanning an open tag as usual, but if we do not notice a terminating '>', we mark the tag as "incomplete". A parser then emits an error for the incomplete tag and adds a synthetic (recovered) element node to the tree with the incomplete open tag's name. What's the downside of this? For one, a breaking change. <ol> <li> The first breaking change is that `<` symbols that are ambiguously text or opening tags will be parsed as opening tags instead of text in element bodies. Take the code ```html <p>a<b</p> ``` Clearly we cannot have the best of both worlds, and this patch chooses to swap the parsing strategy to support the new feature. Of course, `<` can still be inserted as text via the `<` entity. </li> </ol> Part of angular#38596
f0b3e93 to
f48bbe3
Compare
JoostK
approved these changes
Sep 17, 2020
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Let's say we have a code like
Currently this gets parsed into a tree with the element tag
div<span.This has at least two downsides:
</span>doesn't close an element isemitted.
provide correct completions for the opening
<span>tag.This patch attempts to fix both issues by instead parsing the code into
the same tree that would be parsed for
<div></div><span>123</span>.In particular, we do this by optimistically scanning an open tag as
usual, but if we do not notice a terminating '>', we mark the tag as
"incomplete". A parser then emits an error for the incomplete tag and
adds a synthetic (recovered) element node to the tree with the
incomplete open tag's name.
What's the downside of this? For one, a breaking change.
The first breaking change is that
<symbols that are ambiguously textor opening tags will be parsed as opening tags instead of text in
element bodies. Take the code
Clearly we cannot have the best of both worlds, and this patch chooses
to swap the parsing strategy to support the new feature. Of course,
<can still be inserted as text via the
<entity.Part of #38596
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?