This repository has been archived by the owner on Feb 12, 2022. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add abstract serializer mode for test262 execution (#2297)
Summary: I extended the `--serializer` command line argument I added in #2290 to now support `--serializer abstract-scalar`. What this mode does is it converts all boolean, string, number, and symbol literals into abstract values. I did not choose to extend this logic to object and array literals just yet since scalars alone showed some interesting results. What I really want here is a review of the results. Full suite execution results are real bad. **18%** pass rate. I dug a bit into why. ``` === RESULTS === Passes: 3356 / 17780 (18%) ES5 passes: 2276 / 12045 (18%) ES6 passes: 1080 / 5735 (18%) Skipped: 13375 Timeouts: 28 ``` I was mostly interested in the runtime failures we see since that means Prepack is serializing invalid code. However, I found ~14k failures in the Prepack stage (more on this in a bit) and ~3k failures in the runtime stage. This means ~80% of tests _fail to compile_ with this abstract transformation applied. Why are these tests failing? I took the first 4 items of the stack traces from errors thrown in the Prepack stage, sorted, and ranked them. [Here’s the result.](https://gist.github.com/calebmer/29e27613325fd99fa04be7ab4a9641c0) The top 5 with thousands of hits are: ``` 7538 of: at AbstractValue.throwIfNotConcrete (/Users/calebmer/prepack/src/values/AbstractValue.js:536:11) at ToImplementation.ToStringPartial (/Users/calebmer/prepack/src/methods/to.js:717:69) at NativeFunctionValue._index.NativeFunctionValue [as callback] (/Users/calebmer/prepack/src/intrinsics/ecma262/String.js:34:37) at NativeFunctionValue.callCallback (/Users/calebmer/prepack/src/values/NativeFunctionValue.js:121:12) 4595 of: at AbstractValue.throwIfNotConcrete (/Users/calebmer/prepack/src/values/AbstractValue.js:536:11) at NativeFunctionValue.func.defineNativeMethod [as callback] (/Users/calebmer/prepack/src/intrinsics/ecma262/Object.js:328:41) at NativeFunctionValue.callCallback (/Users/calebmer/prepack/src/values/NativeFunctionValue.js:121:12) at functionCall (/Users/calebmer/prepack/src/methods/call.js:308:26) 1454 of: at AbstractValue.throwIfNotConcrete (/Users/calebmer/prepack/src/values/AbstractValue.js:536:11) at NativeFunctionValue.func.defineNativeMethod [as callback] (/Users/calebmer/prepack/src/intrinsics/ecma262/Object.js:364:41) at NativeFunctionValue.callCallback (/Users/calebmer/prepack/src/values/NativeFunctionValue.js:121:12) at functionCall (/Users/calebmer/prepack/src/methods/call.js:308:26) 1351 of: at invariant (/Users/calebmer/prepack/src/invariant.js:18:15) at EvalPropertyNamePartial (/Users/calebmer/prepack/src/evaluators/ObjectExpression.js:59:7) at _default (/Users/calebmer/prepack/src/evaluators/ObjectExpression.js:80:21) at LexicalEnvironment.evaluateAbstract (/Users/calebmer/prepack/src/environment.js:1368:20) 1053 of: at AbstractValue.throwIfNotConcrete (/Users/calebmer/prepack/src/values/AbstractValue.js:536:11) at NativeFunctionValue.obj.defineNativeMethod [as callback] (/Users/calebmer/prepack/src/intrinsics/ecma262/ObjectPrototype.js:35:39) at NativeFunctionValue.callCallback (/Users/calebmer/prepack/src/values/NativeFunctionValue.js:121:12) at functionCall (/Users/calebmer/prepack/src/methods/call.js:308:26) ``` This means there may be some low hanging fruit. Here are my questions for you. - Did you expect results like this? - What is our ideal test262 pass rate with this transformation applied? - What happens to React Compiler or other projects when these errors are thrown? (As I understand it, we bail out and don’t optimize the code, but do optimize the code around it.) - Do you think my methodology is flawed? It’s also possible that something in my methodology is wrong, but I didn’t spend much time investigating these failures as I spent investigating the failures I found in #2290. My goal with this test suite is to build an understanding of what “correctness” for the React Compiler against all JavaScript code looks like. (Not just the few bundles we’ve selected to look at.) I don’t think these results suggest that we only safely compile 18% of the language, but it’s a data point. I’ll be looking into fixing a selection of these issues to better understand their nature or if I need to change methodologies. Pull Request resolved: #2297 Differential Revision: D9120572 Pulled By: calebmer fbshipit-source-id: b394f1e8da034c9985366010e3e63fd55fd94168
- Loading branch information