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 16, 2024 4:51pm

[react-sizebot]

Comparing: e06c72f...ec5bc4e

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	=	510.76 kB	510.76 kB	=	91.36 kB	91.36 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	=	515.55 kB	515.55 kB	=	92.17 kB	92.17 kB
facebook-www/ReactDOM-prod.classic.js	=	594.69 kB	594.69 kB	=	104.93 kB	104.93 kB
facebook-www/ReactDOM-prod.modern.js	=	584.96 kB	584.96 kB	=	103.37 kB	103.37 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against bfeb9b1

[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.