Parser: Treat javascript_tag content as foreign content#1434
Merged
Conversation
425292a to
7187710
Compare
commit: |
🌿 Interactive Playground and Documentation PreviewA preview deployment has been built for this pull request. Try out the changes live in the interactive playground: 🌱 Grown from commit ✅ Preview deployment has been cleaned up. |
7187710 to
be60bfb
Compare
be60bfb to
8fac44a
Compare
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 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 pull request fixes how the parser handles
javascript_tag doblocks when the body contains HTML-like syntax such as<operators in JavaScript expressions (e.g.n <o.length, for (let i = 0; i<items.length; i++)).Previously, the outer HTML parser would interpret
<inside ajavascript_tag dobody as an HTML tag opening, creating a brokenHTMLOpenTagNodethat swallowed the<% end %>closing tag. This caused a null dereference in the analyzer when it tried to accessblock_node->end_node.The fix has two parts:
htmlparser option and foreign content re-parsingA new
htmlparser option (defaults totrue) controls whether the parser runs in HTML mode or foreign content mode. Whenhtml: false, the parser treats everything as literal text and ERB tags, no HTML tag parsing. The analyzer now re-parsesjavascript_tag dobody content withhtml: falseto produce cleanLiteralNodes, regardless of what the outer HTML parse produced.New
start_lineandstart_columnoptions allow the re-parsed body to carry correct source locations from the original template.Swallowed
<% end %>recoveryWhen the outer HTML parse swallows
<% end %>inside a brokenHTMLOpenTagNode, the analyzer walks the AST to find the swallowedERBContentNodewithendcontent. It creates a properERBEndNodefrom it and uses it as theclose_tag, with staleERBControlFlowScopeErrorcleared.For example, the following template with
action_view_helpers: true:Now correctly produces:
Resolves #1426