-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove some closure compiler hacks #8437
Conversation
…libraries means we can know at pre render time which library code is included
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable.
@@ -753,6 +753,7 @@ var LibraryGLFW = { | |||
|
|||
event.preventDefault(); | |||
|
|||
#if '$FS' in addedLibraryItems |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, I didn't know about this "preprocessor syntax"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we made it possible to run arbitrary JS in the preprocessor, I think this was a few months ago.
The hacks for GL are not just ugly, but also bad for code size in some cases, it turns out (apparently closure will not optimize as much in their presence). This is a step towards emscripten-core#8421, the changes for which end up causing closure to emit worse code if not for this PR.
This reverts commit 0439bc1.
This reverts commit 0439bc1.
…JS libraries we have not yet included anything from libraries, so we should not read addedLibraryItems
…e#10058) * Revert part of emscripten-core#8437 - the glfw part was invalid, as when processing JS libraries we have not yet included anything from libraries, so we should not read addedLibraryItems * fix deps. fixes emscripten-core#10004 * ifdef FS code in glfw
The hacks for GL are not just ugly, but also bad for code size in some cases, it turns out (apparently closure will not optimize as much in their presence). This is a step towards emscripten-core#8421, the changes for which end up causing closure to emit worse code if not for this PR.
…e#10058) * Revert part of emscripten-core#8437 - the glfw part was invalid, as when processing JS libraries we have not yet included anything from libraries, so we should not read addedLibraryItems * fix deps. fixes emscripten-core#10004 * ifdef FS code in glfw
The hacks for GL are not just ugly, but also bad for code size in some cases, it turns out (apparently closure will not optimize as much in their presence).
This is a step towards #8421, the changes for which end up causing closure to emit worse code if not for this PR.