[lit-labs/compiler] do not compile templates containing deprecated octal sequences #4088
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
🦋 Changeset detectedLatest commit: dd57252 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultsthis-change
render
update
update-reflect
this-change, tip-of-tree, previous-release
render
update
nop-update
this-change, tip-of-tree, previous-release
render
update
this-change, tip-of-tree, previous-release
render
update
update-reflect
|
Collaborator
justinfagnani
left a comment
There was a problem hiding this comment.
Just a couple style nits. Looks great!
| // - Chromium octal escape sequence scanner: | ||
| // https://source.chromium.org/chromium/chromium/src/+/181fa1f62f501c27ed19fcb69206a0e2e1eff513:v8/src/parsing/scanner.cc;l=452-460 | ||
| if (/^([^\\|\s]|\\.)*?\\(0)*[1-9]/gm.test(staticString)) { | ||
| return {shouldCompile: false}; |
Collaborator
There was a problem hiding this comment.
If this will cause a warning at runtime, why don't we error or log a warning here?
Thinking ahead, ultimately we'd like to be able to use the compiler to drop the template prep code from the client bundle. We'll need to compile every template for that.
Contributor
Author
There was a problem hiding this comment.
That is a great point. Currently the compiler has been implemented in a conservative manner where any prepare phase DEV_MODE warnings simply don't compile the template – deferring it to runtime.
E.g.:
- dynamic tag binding
- bindings in
<template>|<textarea> - octal escape
This technique feels like it should be the easiest for adoption, because we are very specific about what to compile. But, I agree that we need a strategy into informing and helping developers fix the issues that deoptimize templates so we can get to that world with complete removal of prepare in certain projects.
Do you think adding console.warn is a reasonable starting goal?
justinfagnani
approved these changes
Aug 12, 2023
rictic
approved these changes
Aug 14, 2023
Collaborator
rictic
left a comment
There was a problem hiding this comment.
Awesome work, and great comments!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Issue: #189
RFC: lit/rfcs#21
Full prototype PR: #3984
Context
This is part of handling all the edge cases we test in lit-html.
We specifically throw a dev warning if someone uses a deprecated octal escape sequence in their template. Unfortunately the compiler doesn't use this code path, and the prepared template will also skip this code path.
This is important because a TTL containing one of these escape sequences will get an
undefinedentry in the TTL's static strings array in whichever index contained that deprecated escape.Without this change, the following template:
Will render nothing at all with an uncompiled template (and throw a DEV_MODE warning).
However when compiled, it instead renders the text
undefined.Fix
Hand roll detection of these deprecated octal escape sequences, and do not compile those templates. This would then allow the runtime lit DEV_MODE warning to inform the user.
We could also add a warning to the compiler detection.
Risk
The main risk of this change is a bug in the regex resulting in deoptimizations due to false positives preventing template optimization. This behavior is more correct than what currently happens with these sequences.
Alternatives
\9" throws natively. Could we somehow construct that from the ast raw string and catch the error? I couldn't think of any way that doesn't result inevalorFunctionexploits.