Fix handling of JS keyword for imported functions, types and statics, and when causing invalid code gen #4329
Conversation
This file contains 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
daxpedda
requested changes
Dec 6, 2024
|
Done. Thanks for the suggestions! |
daxpedda
requested changes
Dec 7, 2024
daxpedda
reviewed
Dec 8, 2024
daxpedda
approved these changes
Dec 8, 2024
|
Thanks for the prompt fix - much appreciated! |
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.
Fixes #4317
Fixes #4328
As I said in #4317, keyword handling was kind of a mess. Keywords are now handled correctly for both imports and exports AFAICT.
Changes:
js_namespace. Now, the first identifier cannot be a JS keyword and empty lists are no longer allowed. This is not a breaking change, because keyword identifiers resulted in invalid JS code gen, and empty lists crashed the CLI.js_nameexist. The list now includes all JS keywords.About the keyword list update: I also add keywords that are only keywords in strict mode. JavaScript has 2 execution modes: strict mode and sloppy mode. Sloppy mode is the legacy mode and shouldn't be used anymore. The key takeaway here is that we should only generate code that works in strict mode, so we must not allow identifiers that are keywords in strict mode. This is important, because all JS files that use ESM (
import/export) implicitly use strict mode. I don't want WBG to be in the situation where it only generates valid JS for some CLI targets.Lastly,
await.awaitis a keyword ONLY isasyncfunctions in JS. So it can generally be used as an identifier, but this can cause problems. If a class is namedawait, then this class cannot be used insideasyncfunctions. It's a weird edge case, and I'm not sure whether we should considerawaita reserved keyword too. Right now, I just allowed it.