Upgrade to google-closure-compiler v20230502

[davesnx]

Update gcc to 20230502 since #31587 fails with dynamic imports but in the linked issue they mention that might be a regression from 20230502, so trying to install this.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 19, 2024 0:45am

[react-sizebot]

Comparing: a9bbe34...a2b73eb

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	511.38 kB	511.38 kB	=	91.38 kB	91.38 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	517.53 kB	517.53 kB	=	92.34 kB	92.34 kB
facebook-www/ReactDOM-prod.classic.js	=	593.09 kB	593.09 kB	=	104.45 kB	104.45 kB
facebook-www/ReactDOM-prod.modern.js	=	583.35 kB	583.35 kB	=	102.90 kB	102.90 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 8049ab4

[eps1lon]

Doesn't help with #31578 as far as I can tell.

[davesnx]

I can't test it with codesandbox (fails to fetch from https://react-builds.vercel.app), neither locally (don't have java installed). I pushed a unit test to ensure it, and I guess I should be able to see it on the CI with yarn test --env=development

[eps1lon]

You can test this locally with yarn build react-dom/client --type=NODE_DEV (we apply GCC to
dev bundles as well) and then check the build artifact for "JSCompiler_OptimizeArgumentsArray_". I won't have time to approve CI runs for every push.

[davesnx]

Time to install some Java@11, then!

[davesnx]

After reading about gcc I found nocollapse from https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#nocollapse and added // @nocollapse into arguments.

This seems to do the job fine but hard to say if it's the right solution. After using @noalias (https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#noalias) it does seem to bail out from the optimization for arguments.

Also, it is worth noticing that my unit test is rather useless. If this goes to be the right solution, I might keep this PR just updating the gcc version and pushing another PR.

[eps1lon]

You can also use #31598 as a basis. That lints against the optimization which makes sure new code doesn't forgot to disable this optimization.

[github-actions]

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.

[github-actions]

Closing this pull request after a prolonged period of inactivity. If this issue is still present in the latest release, please ask for this pull request to be reopened. Thank you!