Summary:
cc NTillmann
Following up https://github.com/facebook/prepack/issues/2285, website shows the generated coded even when there are some warnings.
Lot of changes because prettier wasn't applied to the files, but I basically only checked for the error buffer containing only items with `severity === 'Warning'` and create the `warning` result type to behave the same than `success` one.
Next step would be to show the code AND warning messages. Either using the same display than error messages or creating a variation of it (changing text color to yellow for example). I can do it if you want.
Let me know if this is what you were looking for.
Have a nice day !
P.S: not sure if this PR was supposed to be into `gh-pages` or `master`. Let me know if that needs to be changed.
Pull Request resolved: https://github.com/facebook/prepack/pull/2528
Differential Revision: D9882040
Pulled By: NTillmann
fbshipit-source-id: bc8266a673e6def023bfa65b93b94ea9c7ad5b1d
Summary:
Release Notes: None
This PR makes it so we no longer report conflicts for child optimized functions reading from values that their parents have written.
Couple of things for discussion:
- This creates somewhat confusing behavior because the child functions will take the concrete value after the parent functions' effects have been applied:
```javascript
(function () {
let obj = {p: 42};
function f() {
obj.p += 3;
function g() { return obj.p; } // Will optimize to `return 47;`
obj.p += 1;
__optimize(g);
obj.p += 1;
return g;
}
__optimize(f);
global.f = f;
})();
```
- This PR creates the Parent/Child relationship based off `AdditionalFunctionEffects.parentAdditionalFunction` which goes off of syntactic nesting of functions instead of nesting of `__optimize` calls as in the issue. I believe basing the nesting off of `__optimize` calls could lead to somewhat unintuitive results (especially considering we store `parentAdditionalFunction` in `AdditionalFunctionEffects` to be the syntactic parent).
I am not sure if it is needed by Instant Render NTillmann? If it is, we may want to consider changing `AdditionalFunctionEffects.parentAdditionalFunction` to be based off of `__optimize` call nesting as well for consistency.
As an example a slight modification on the example above:
```javascript
(function () {
let obj = {p: 42};
function g() { return obj.p; }
function f() {
obj.p += 3;
__optimize(g);
obj.p += 1;
return [g, obj];
}
__optimize(f);
global.f = f;
})();
```
With this PR, we report an error. Based off of `__optimize` nesting, we would optimize `g` to `return 46;`. I would expect to see `return 42;` `return 45;` or `return obj.p;` in this case.
- To resolve the above issues, in the future, we could make any values modified by parent optimized functions into abstract values during evaluation for child optimized functions to force their accesses to be recorded in generators .
Resolves#2351
Pull Request resolved: https://github.com/facebook/prepack/pull/2542
Differential Revision: D9803741
Pulled By: cblappert
fbshipit-source-id: baca233c8de81633332b25f0776ed1a9d6c95a60
Summary:
This can be a possible fix for https://github.com/facebook/prepack/issues/2509
I have removed the `invariant` method call and added a value check as used for the _invariantMode_ option.
`node lib/prepack-cli.js --debugDiagnosticSeverity foo`
will now generate
`Unsupported debugDiagnosticSeverity: foo`
Pull Request resolved: https://github.com/facebook/prepack/pull/2545
Differential Revision: D9800485
Pulled By: hermanventer
fbshipit-source-id: edc24b4a812b4e32f9c48e05a0799bf4af431991
Summary:
Release notes: None
Otherwise, this could cause issues, as path conditions get captured e.g. in generators.
Pull Request resolved: https://github.com/facebook/prepack/pull/2538
Reviewed By: hermanventer
Differential Revision: D9762541
Pulled By: NTillmann
fbshipit-source-id: 4d12681e3921d2c0f10f3c9f3f0702823a2b0d99
Summary:
Release notes: Fixes invariant violation regression when using webpack-prepack-plugin
This fixes#2540.
I didn't actually test it end-to-end webpack-prepack-plugin, would be great if someone could do that. We need some kind of end-to-end test for this to avoid regressions in the future.
Pull Request resolved: https://github.com/facebook/prepack/pull/2541
Differential Revision: D9756803
Pulled By: NTillmann
fbshipit-source-id: 2bded0dcb0a16369f3d3ff41c2f4d5181c75d67c
Summary:
Release note: none
Closes#2435Closes#1829
Join.composeWithEffects composes a forked completion with subsequent effects. When two or more forks could end normally, this could result in shallow copies of the subsequent effects. These were then joined together and applied, so it was mostly OK. The generator of the subsequent effects, however, ended up being joined with itself and thus transformed the generator tree to a DAG, which is not desirable for the serializer.
The new approach is to extract a join condition from the forked completion and using it to join the subsequent effects with a newly constructed empty effects. The condition ensures that the subsequent effects are applied only in situations where the forked completion is not abrupt.
Extracting this condition makes for complicated abstract expressions and this uncovered some existing bugs and limitations that are also addressed in this pull request. As a side effect, path conditions are now longer and the time to compile unrolled loops with conditional abrupt completions inside their bodies has gone up so much that the unroll limit had to be lowered.
Please note that the expected output React tests has changed because of re-ordering. I'm none too sure that this re-ordering is necessarily benign, so please review carefully.
Pull Request resolved: https://github.com/facebook/prepack/pull/2523
Differential Revision: D9623729
Pulled By: hermanventer
fbshipit-source-id: 737096bba54a7a2ad300dc29882ea1b7829ac745
Summary:
Release notes: providing __replaceFunctionImplementation_unsafe built-in
This new built-in allows replacing the method implementation (capture environment, body, ...) of source functions.
As a result, all method calls executed by the Prepack interpreter will be redirected,
and the replacement will carry over to the prepacked code.
Pull Request resolved: https://github.com/facebook/prepack/pull/2533
Reviewed By: hermanventer
Differential Revision: D9693654
Pulled By: NTillmann
fbshipit-source-id: bd28997965e641f58f89f7119fa477c535c0e539
Summary:
Release note: none
This attempts to reduce exponential blowup in the simplifier by doing more caching while computing implications and by imposing a depth limit on the number of simplify and implies calls.
It also tries to make implies and impliesNot more symmetrical, so that things are less ad-hoc.
Pull Request resolved: https://github.com/facebook/prepack/pull/2530
Differential Revision: D9664026
Pulled By: hermanventer
fbshipit-source-id: f7a9135b06298a2b77ad05bf377982a9b37e4ad1
Summary:
Release notes: none
Fixes a bug where `reactFailOnUnsupportedSideEffects` should evaluate to `false` if passed as false. Also fixes a lint issue on `master`.
Pull Request resolved: https://github.com/facebook/prepack/pull/2532
Differential Revision: D9662462
Pulled By: trueadm
fbshipit-source-id: 1ffeea55e55a2bde9f1d44c64ac85d7e1b1727cf
Summary:
- Fixed bugs that could cause generated code to throw
- Improved evaluation of abstract conditionals
- Added CLI options --warnaserror, --diagnosticaserror, --nodiagnostic
- Added full support for React.Children.map mock
- Support constructors that return an object but also throw
Reviewed By: yinghuitan
Differential Revision: D9660870
fbshipit-source-id: 49674fae56538809f6f962e49291be77f3617d2c
Summary:
Release notes:
This adds a `reactFailOnUnsupportedSideEffects` flag for React internal testing with `debug-fb-www` and ignores `try/catch` PP0021 errors for internal testing too. These are intended to be temporary changes purely for internal FB testing.
Pull Request resolved: https://github.com/facebook/prepack/pull/2531
Differential Revision: D9656578
Pulled By: trueadm
fbshipit-source-id: 9339dd8245e5a03d567ca2fd8e24e90152f1e22b
Summary:
Release notes: Fixed bugs that could cause generated code to throw
A refactor of my previous attempt to address #2327, which I had to abandon because it was incompatible with the current implementation of certain modeling primitives. Like the previous version, this PR is an intermediate fix that will be refined in a follow up PR. It consists of three changes:
1) It adds a new helper that discharges values from a union after deriving the abstract value in it if needed.
2) It makes conditionally temporal values safe using a helper called `convertToTemporalIfArgsAreTemporal`.
3) It makes the the abstract and concrete members explicit in the interface to Abstract Concrete Unions. Presently, two code sites make the assumption that the abstract member is the first element of `args`, while all others traverse the list to locate it.
Follow ups to come:
1) Update `convertToTemporalIfArgsAreTemporal` to produce a conditional value left to be simplified by the serializer.
2) Enforce the protocol *temporal args should imply temporal results* more generally (#2489).
Fixes#2327 and #2406
Pull Request resolved: https://github.com/facebook/prepack/pull/2513
Differential Revision: D9636173
Pulled By: sb98052
fbshipit-source-id: 22d63dfb9d0da4b1f6eba4e2f6f88760f5eb03ca
Summary:
Release notes: none
Currently, when don't really fully deal with abstract conditions fully throughout the Prepack codebase and we usually simply leak/emit a temporal to get around them. So this PR aims at tackling many of the code-sites where they are prevalent by using the internal React bundle to find most of them and address them – with the goal of improving evaluation in cases where we run into conditionals.
With this PR, we now try and resolve different parts of the condition, including conditionals such as `||` and `&&`. This allows us to evaluate potentially far more than before when it comes to product code where we inhabit many deep conditionals. These changes also impact `Object.assign` as it triggered an invariant with `getSnapshot` as it never expected a conditional there. This should also fix https://github.com/facebook/prepack/issues/2323.
I've added some tests to show this but here is an example of the output before and after:
```js
// Input
function fn(x, b) {
var a = x ? b : { a: 2 };
return a.a;
}
// Before
var _2 = function (x, b) {
var _3 = {};
_3.a = 2;
var _$0 = (x ? b : _3).a;
return _$0;
};
// After
var _2 = function (x, b) {
if (x) {
var _$0 = b.a;
}
return x ? _$0 : 2;
};
```
For conditional `Object.assign`, the output looks like this (note: we need materializing rather than leaking to better improve the output):
```js
// Input
function fn(x) {
var a = x ? { a: 1 } : { a: 2 };
return Object.assign({}, a, { b: 1 });
}
// Before
var _2 = function (x) {
var _$0 = {
a: 1
};
var _$1 = {
a: 2
};
({}).a = 1;
({}).a = 2;
var _$2 = {
b: 1
};
var _9 = {};
var _$3 = _$9(_9, x ? _$0 : _$1, _$2);
return _9;
};
// After
var _2 = function (x) {
return {
a: x ? 1 : 2,
b: 1
};
};
```
I also took the time to apply the same small changes to the existing code in `CallExpression` so the logic there could also handle `&&` and `||` cases too. Including is a React test that shows that we can now inline a component that we previously weren't able to do.
Pull Request resolved: https://github.com/facebook/prepack/pull/2503
Differential Revision: D9616500
Pulled By: trueadm
fbshipit-source-id: 3888a62da330c64b0395723f8764c3590adc8491
Summary:
Release notes: `test-internal-react` and `test-internal` now use `--max_old_space_size=32768`
As per the title, this increases the max memory allocation for Node to 32gb. `--max_old_space_size=32768`.
Pull Request resolved: https://github.com/facebook/prepack/pull/2524
Differential Revision: D9618037
Pulled By: trueadm
fbshipit-source-id: 6bd595410c6f93ccc5abbc116ee892e8de519eed
Summary:
Release notes: Adding CLI options --warnaserror, --diagnosticaserror, --nodiagnostic
This resolves#2517.
- --warnAsError: Turns all warnings into errors.
- --diagnosticAsError: Must be followed by a comma-separated list of non-fatal-error PPxxxx diagnostic codes that should get turned into (recoverable) errors.
- --noDiagnostic: Must be followed by a comma-separated list of non-fatal-error PPxxxx diagnostic codes that should get suppressed.
Adding tests.
Pull Request resolved: https://github.com/facebook/prepack/pull/2521
Differential Revision: D9616473
Pulled By: NTillmann
fbshipit-source-id: c66d7396005699d4d50f801a419fa4879bd8ffc4
Summary:
Release notes: none
The `React.Children.map` mock was not fully finished and had side-effects. This fixes that and adds a test to show it properly working.
Pull Request resolved: https://github.com/facebook/prepack/pull/2519
Differential Revision: D9614166
Pulled By: trueadm
fbshipit-source-id: b646d13cc46f3747b07a111dc5bc9de295e25212
Summary:
This PR implements a step of the way to getting leaked value analysis working for optimized Array operators. It is desirable to leak as little as possible, so that the operators can be specialized to take into account values in the environment in which they run. In the beginning, we are focusing on the narrow range of scenarios in which this is possible. We will start by enforcing the assumptions that we rely on, and make sure that the code that we generate is correct. Once we have correct code, we will start progressively relaxing the assumptions to increase coverage. The overall plan can be found here: #2452.
More specifically, this PR transitively materializes objects reachable via reads to bindings in the optimized function. This is necessary to snapshot the contents of those objects at specialization time.
Fixes#2405.
Pull Request resolved: https://github.com/facebook/prepack/pull/2456
Differential Revision: D9498939
Pulled By: sb98052
fbshipit-source-id: 16853f97dc781505dba29dce7f28996a0a4e7749
Summary:
Release notes: landing two previously reverted PRs
I found the issue.
Flow doesn't support optional fields in classes. This effectively becomes enforced with Babel 7 since it treats the type annotations as field initializers. Which means that these fields always gets created.
We happened to only use this newer plugin for class fields internally which broke our builds only there.
2b4546d Use `undefined` instead of missing to represent absent field in descriptors. Fixed all the callsites that checks for `hasOwnProperty` or `in` that I could find.
922d40c Fixes a Flow issue in the text printer.
I filed a [follow up issue for ObjectValue](https://github.com/facebook/prepack/issues/2510) since it has the same problem.
Pull Request resolved: https://github.com/facebook/prepack/pull/2511
Reviewed By: trueadm
Differential Revision: D9569949
Pulled By: sebmarkbage
fbshipit-source-id: f8bf84c4385de4f0ff6bcd45badacd3b8c88c533
Summary:
This fixes a bug it took me a while to track down. Unfortunately creating a repro was really difficult. I was observing the following invariant in `Reference` being triggered.
fddfc6f0c5/src/environment.js (L1425-L1431)
Digging in, the bad base was a deep conditional `AbstractValue` where all the leaf nodes were `EmptyValue` and `__bottomValue`. (Constructed from a number of `try`/`catch`/`throw`s.) This `AbstractValue` _should_ have simplified to just `EmptyValue` then `RequireObjectCoercible()` should have thrown a runtime `TypeError` after seeing the `EmptyValue`. This is what I observed in local tests when trying to reproduce this issue.
After looking at the error in the large React Native bundle I’m working in I discovered that the simplifier was throwing an error since the simplification count was exceeded. This is fine and normal. The issue was that `RequireObjectCoercible()` does not handle complex empty `AbstractValue`s well. If failing simplification is a normal part of Prepack operation we should make sure methods like `RequireObjectCoercible()` can handle complex `AbstractValue`s as well as simple ones.
This PR does that.
Pull Request resolved: https://github.com/facebook/prepack/pull/2515
Reviewed By: trueadm
Differential Revision: D9602146
Pulled By: calebmer
fbshipit-source-id: 359c74c646eeb619ba2e78b50eafe10b2e2fb133
Summary:
Release note: none
Closes#2435Closes#1829
Join.composeWithEffects composes a forked completion with subsequent effects. When two or more forks could end normally, this could result in shallow copies of the subsequent effects. These were then joined together and applied, so it was mostly OK. The generator of the subsequent effects, however, ended up being joined with itself and thus transformed the generator tree to a DAG, which is not desirable for the serializer.
The new approach is to extract a join condition from the forked completion and using it to join the subsequent effects with a newly constructed empty effects. The condition ensures that the subsequent effects are applied only in situations where the forked completion is not abrupt.
Extracting this condition makes for complicated abstract expressions and this uncovered some existing bugs and limitations that are also addressed in this pull request. As a side effect, path conditions are now longer and the time to compile unrolled loops with conditional abrupt completions inside their bodies has gone up so much that the unroll limit had to be lowered.
Please note that the expected output React tests has changed because of re-ordering. I'm none too sure that this re-ordering is necessarily benign, so please review carefully.
Pull Request resolved: https://github.com/facebook/prepack/pull/2460
Reviewed By: trueadm
Differential Revision: D9486135
Pulled By: hermanventer
fbshipit-source-id: 87147384c285e051542c277e41b3176b91ab165d
Summary:
Release note: none
This fixes two problems uncovered while debugging the failure of PR #2460 when run on a large internal test case:
1) CSE did not fix up recently introduced aliases of expressions.
2) The serializer logic visited array elements that were not visited because of recently introduced leak logic.
Pull Request resolved: https://github.com/facebook/prepack/pull/2516
Differential Revision: D9599235
Pulled By: hermanventer
fbshipit-source-id: a2047227b4aa2e0e2def7d8e7ebe0724a9525160
Summary:
Highlights:
Make simplification more robust when complexity limits are reached
reduces loop iteration counter to 6 before bailing out
We weren’t using the correct `initializerAstNodeName` in two places
Tease apart expressions vs. statements for operation descriptors
Simplify equality expressions where types are known
Refactor AbstractObjectValue to use evaluateWithAbstractConditional
Allow invalid render return values in the React reconciler
update Babel 7 to stable release
Speed up simplifier by using an implication cache per path branch
Add basic support for throws in React
Reviewed By: hermanventer
Differential Revision: D9597756
fbshipit-source-id: 6009ddb70f8b68151bf26ac8c15320213f67dcfc
Summary:
The following example fails with an invariant:
```js
try {
try {
const b = __abstract("boolean", "false");
if (b) throw new Error("throw");
} catch (error) {}
} catch (error) {
console.log(error.message);
}
```
```
Invariant Violation: assuming that false equals true is asking for trouble
debug-fb-www.js:208
This is likely a bug in Prepack, not your code. Feel free to open an issue on GitHub.
at invariant (/Users/calebmer/prepack/src/invariant.js:18:15)
at PathImplementation.withCondition (/Users/calebmer/prepack/src/utils/paths.js:132:17)
at joinTryBlockWithHandlers (/Users/calebmer/prepack/src/evaluators/TryStatement.js:81:35)
at _default (/Users/calebmer/prepack/src/evaluators/TryStatement.js:30:47)
at LexicalEnvironment.evaluateAbstract (/Users/calebmer/prepack/src/environment.js:1379:20)
at LexicalEnvironment.evaluate (/Users/calebmer/prepack/src/environment.js:1367:20)
at LexicalEnvironment.evaluateCompletion (/Users/calebmer/prepack/src/environment.js:1102:19)
at LexicalEnvironment.evaluateCompletionDeref (/Users/calebmer/prepack/src/environment.js:1095:23)
at _default (/Users/calebmer/prepack/src/evaluators/Program.js:235:17)
at LexicalEnvironment.evaluateAbstract (/Users/calebmer/prepack/src/environment.js:1379:20)
```
What happens is we end up with a completion structure as follows when going into the outer `catch`:
```
- JoinedNormalAndAbrubtCompletions (joinCondition = x)
- SimpleNormalCompletion
- JoinedNormalAndAbrubtCompletions (joinCondition = x)
- ThrowCompletion
- SimpleNormalCompletion
```
The inner `JoinedNormalAndAbrubtCompletions` is the inner `try` block completion. The outer `JoinedNormalAndAbrubtCompletions` is the join of the inner `try`/`catch` blocks. Notably the `ThrowCompletion` is completely unreachable. However it is still there.
Ideally we would refine the completions. I tried this, but realized the `composedWith`, `pathConditionsAtCreation`, and `savedEffects` on `JoinedNormalAndAbrubtCompletions` were more to handle then I originally bargained for to fix my original test case. Instead I picked a simple fix for this specific case of `try`/`catch`. When we `AbstractValue.createJoinConditionForSelectedCompletions` we get a concrete `false` value. So I check if it is false and don’t execute the catch block if it is. The condition can never be concretely true. Otherwise we’d unconditionally catch an error in the block above.
Happy to take suggestions for a more general fix.
Pull Request resolved: https://github.com/facebook/prepack/pull/2507
Differential Revision: D9583244
Pulled By: calebmer
fbshipit-source-id: 7693efef5e967c90d5a4c54f10ef2c137f264ef8
Summary:
Release notes: none
Looking through our internal bundles and there are frequent cases where `instanceof` is used where the left-hand side is a primitive and the right-hand side is an abstract value. In the case where the left-hand side is a primitive and the right-hand side is a simple object, the instanceof binary expression should always return `false`.
Pull Request resolved: https://github.com/facebook/prepack/pull/2506
Differential Revision: D9567344
Pulled By: trueadm
fbshipit-source-id: 7333f3b81627657c184c77d4cfffd4511bee0cbf
Summary:
Starts adding basic support for throws in React. Concretely there are three things this PR does outside of adding tests:
1. Allowing throw side-effects.
2. Removing an invalid invariant. `createdObjects` changes after calling `realm.captureEffects()` and this is expected. Later code which joins/incorporates effects will merge in the captured `createdObjects`.
3. Don’t catch `AbruptCompletion`s and handle them as errors. Instead let them propagate up to the nearest `realm.evaluateForEffects()`. (Or similar function.)
I have not run this against the internal web bundle yet. Against the internal React Native bundle we get pretty far without removing throws with these changes.
Pull Request resolved: https://github.com/facebook/prepack/pull/2502
Reviewed By: trueadm
Differential Revision: D9566580
Pulled By: calebmer
fbshipit-source-id: 3716a6afd5fc3ae824182ee50e38e51d72126dc2
Summary:
Release notes: none
Fixes mixing functionality from React.cloneElement, where the original ReactElement props where missing from being copied to the new props.
Pull Request resolved: https://github.com/facebook/prepack/pull/2505
Differential Revision: D9565338
Pulled By: trueadm
fbshipit-source-id: f04c15b3a640f87de6de8326511e8e4bdfa328a7
Summary:
Release notes: None
This resolves#1944.
The functionality that Prepack provides can be seen as being done by two separate engines:
1) There's the "front-end", which does symbolic execution / abstract interpretation,
computing "effects" / "generator trees" for the global code and optimized functions.
2) There's the "back-end", which takes this intermediate representation, computes what's
reachable, and then turns it into a new executable program by performing transformations
such as breaking cycles.
Before, Prepack developers had very few tools available to understand what goes on between the
front-end and back-end. Usually, they just look at the final output, imagine what the
intermediate representation might have been, or maybe use to debugger to poke around
memory locations, or to invoke helper functions to inspect live state that way, hoping the debugger doesn't crash along the way.
This PR (and other associated PRs such as #2490, #2491) try to improve that state by turning the intermediate representation into a first-class data structure that is printable into a human-readable textual form. This will help...
- in understanding what's going on
- enabling different back-ends by ensuring that there's a first-class intermediate representation
- enabling future transformations on a well-defined intermediate data structure, ideally breaking up what the current serializer implementation does
- new ways of testing, e.g. via snapshots of the intermediate representation, or
(once there is a parser) feeding hand-written IR into the back-end
For example, for this program...
```js
let x = __abstract("number", "(x)");
if (x > 42) {
let t = Date.now();
let u = 2 + 3
console.log(t + u);
} else {
global.result = x;
}
```
... the IR would currently look like this:
```
(entry point): "main(#0)"
* value#0 = ">"(@"(x)", 42)
if value#0
then: "evaluateNodeForEffects(#4)"
path conditions value#0
_$0 := ABSTRACT_FROM_TEMPLATE<template source @"global.Date.now()">[isPure]
* value#1 = "+"(5, _$0)
CONSOLE_LOG("log", value#1)
else: "evaluateNodeForEffects(#11)"
* value#2 = "!"(value#0)
path conditions value#2
GLOBAL_ASSIGNMENT(@"(x)", "result")
```
Notes:
- Indentation reflects structure of the generator tree
- Each line encodes some information. Some of the information is atemporal, e.g.
- `* value#N = f(args)` // atemporal abstract value
- Some of the information is temporal, e.g.
- `_$N := op-type<op-data>(args)[metadata]` // generator entry that defines a temporal value
- `op-data` contains various essential data
- `args` tends to be a projection of `data` capturing all values that must be visited, but it's not consistent
- `metadata` is information that helps the visitor compute minimal reachability, but it's not semantically relevant.
- `op-type<op-data>(args)[metadata]` // generator entry that does not define a temporal value
- `if ... then ... else`.
```js
(function() {
let obj = {};
obj.p = obj;
global.result = obj;
})();
```
=>
```
(entry point): "main(#0)"
* object#14 = ObjectValue(properties [p], $Prototype @"Object.prototype")
* object#14.p = PropertyBinding(descriptor PropertyDescriptor(writable, enumerable, configurable, value object#14))
GLOBAL_ASSIGNMENT(object#14, "result")
```
Things get slightly ugly with functions.
```js
function f() { }
```
=>
```
(entry point): "main(#0)"
* declEnv#1 = DeclarativeEnvironmentRecord()
* globEnv#2 = GlobalEnvironmentRecord($DeclarativeRecord declEnv#1, $ObjectRecord declEnv#1, $VarNames [f], $GlobalThisValue global)
* lexEnv#0 = LexicalEnvironment(destroyed, environment record globEnv#2)
* func#13 = ECMAScriptSourceFunctionValue($ConstructorKind base, $ThisMode global, $FunctionKind normal, $FormalParameters 0, $Environment lexEnv#0, properties [arguments, length, caller, prototype, name], $Prototype @"Function.prototype")
* func#13.arguments = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value undefined))
* func#13.length = PropertyBinding(descriptor PropertyDescriptor(configurable, value 0))
* func#13.caller = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value undefined))
* object#14 = ObjectValue(properties [constructor], $Prototype @"Object.prototype")
* object#14.constructor = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value func#13))
* func#13.prototype = PropertyBinding(descriptor PropertyDescriptor(writable, value object#14))
* func#13.name = PropertyBinding(descriptor PropertyDescriptor(configurable, value "f"))
GLOBAL_ASSIGNMENT(func#13, "f")
```
Things get really ugly with optimized functions, but that's what it is right now:
```js
function f() { return 2 + 5; }
__optimize(f);
```
=>
```
(entry point): "main(#0)"
* declEnv#1 = DeclarativeEnvironmentRecord()
* globEnv#2 = GlobalEnvironmentRecord($DeclarativeRecord declEnv#1, $ObjectRecord declEnv#1, $VarNames [f], $GlobalThisValue global)
* lexEnv#0 = LexicalEnvironment(destroyed, environment record globEnv#2)
* func#13 = ECMAScriptSourceFunctionValue($ConstructorKind base, $ThisMode global, $FunctionKind normal, $FormalParameters 0, $Environment lexEnv#0, properties [arguments, length, caller, prototype, name], $Prototype @"Function.prototype")
* func#13.arguments = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value undefined))
* func#13.length = PropertyBinding(descriptor PropertyDescriptor(configurable, value 0))
* func#13.caller = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value undefined))
* object#15 = ObjectValue(properties [constructor], $Prototype @"Object.prototype")
* object#15.constructor = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value func#13))
* func#13.prototype = PropertyBinding(descriptor PropertyDescriptor(writable, value object#15))
* func#13.name = PropertyBinding(descriptor PropertyDescriptor(configurable, value "f"))
GLOBAL_ASSIGNMENT(func#13, "f")
=== optimized function func#13
(entry point): "AdditionalFunctionEffects(#12)"
RETURN(7)
* object#16 = ArgumentsExotic(properties [length, callee], symbols [@"Symbol.iterator"], $Prototype @"Object.prototype")
* object#16.length = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value 0))
* declEnv#1 = DeclarativeEnvironmentRecord()
* globEnv#2 = GlobalEnvironmentRecord($DeclarativeRecord declEnv#1, $ObjectRecord declEnv#1, $VarNames [f], $GlobalThisValue global)
* lexEnv#0 = LexicalEnvironment(destroyed, environment record globEnv#2)
* func#13 = ECMAScriptSourceFunctionValue($ConstructorKind base, $ThisMode global, $FunctionKind normal, $FormalParameters 0, $Environment lexEnv#0, properties [arguments, length, caller, prototype, name], $Prototype @"Function.prototype")
* func#13.arguments = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value undefined))
* func#13.length = PropertyBinding(descriptor PropertyDescriptor(configurable, value 0))
* func#13.caller = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value undefined))
* object#15 = ObjectValue(properties [constructor], $Prototype @"Object.prototype")
* object#15.constructor = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value func#13))
* func#13.prototype = PropertyBinding(descriptor PropertyDescriptor(writable, value object#15))
* func#13.name = PropertyBinding(descriptor PropertyDescriptor(configurable, value "f"))
* object#16.callee = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value func#13))
* object#16.@"Symbol.iterator" = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value @"Array.prototype.values"))
* object#16.$Prototype = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value @"Object.prototype"))
* object#16.$Extensible = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value true))
* object#16._isPartial = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#16._isLeaked = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#16._isSimple = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#16._simplicityIsTransitive = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#16._isFinal = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#17 = ObjectValue($Prototype null)
* object#17.$Prototype = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value null))
* object#17.$Extensible = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value true))
* object#17._isPartial = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#17._isLeaked = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#17._isSimple = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#17._simplicityIsTransitive = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#17._isFinal = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#18 = ObjectValue(properties [next], $Prototype @"([][Symbol.iterator]().__proto__.__proto__)")
* func#19 = NativeFunctionValue(properties [length, name], $Prototype @"Function.prototype")
* func#19.length = PropertyBinding(descriptor PropertyDescriptor(configurable, value 0))
* func#19.name = PropertyBinding(descriptor PropertyDescriptor(configurable, value "next"))
* object#18.next = PropertyBinding(descriptor PropertyDescriptor(writable, configurable, value func#19))
* object#18.$Prototype = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value @"([][Symbol.iterator]().__proto__.__proto__)"))
* object#18.$Extensible = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value true))
* object#18._isPartial = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#18._isLeaked = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#18._isSimple = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#18._simplicityIsTransitive = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#18._isFinal = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* object#18.$IteratedList = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(some array))
* func#19.$Prototype = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value @"Function.prototype"))
* func#19.$Extensible = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value true))
* func#19._isPartial = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* func#19._isLeaked = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* func#19._isSimple = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* func#19._simplicityIsTransitive = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
* func#19._isFinal = PropertyBinding(internal slot, descriptor InternalSlotDescriptor(value false))
modified property bindings: [object#16.$Prototype, object#16.$Extensible, object#16._isPartial, object#16._isLeaked, object#16._isSimple, object#16._simplicityIsTransitive, object#16._isFinal, object#17.$Prototype, object#17.$Extensible, object#17._isPartial, object#17._isLeaked, object#17._isSimple, object#17._simplicityIsTransitive, object#17._isFinal, object#16.length, object#16.@"Symbol.iterator", object#16.callee, object#18.$Prototype, object#18.$Extensible, object#18._isPartial, object#18._isLeaked, object#18._isSimple, object#18._simplicityIsTransitive, object#18._isFinal, object#18.$IteratedList, func#19.$Prototype, func#19.$Extensible, func#19._isPartial, func#19._isLeaked, func#19._isSimple, func#19._simplicityIsTransitive, func#19._isFinal, func#19.length, func#19.name, object#18.next]
created objects: [object#16, object#17, object#18, func#19]
result: SimpleNormalCompletion(value 7)
```
There are still a good number of things left to do. In particular:
- further simplify printing to make it more readable (and writable)
- further extend printed format to make it round-trippable
- some details of the current IR is really just an artefact of 2 years of hacking. It is in need of some additional
rounds of refactorings and simplifications.
- Particularly problematic / overly complicated are invariants INVARIANT, FULL_INVARIANT_ABSTRACT, FOR_IN, REACT_SSR_TEMPLATE_LITERAL
- In `TemporalOperationEntry`, there's some duplication going on with `args` and `data`. Consider eliminating `args` and deriving this information when needed from `data`.
- `OperationDescriptorData` could use some structure, or a (sub)type hierarchy.
- There are already dedicated generator entry classes for some operations, and then there is `TemporalOperationEntry` with its `data` dumping ground for everything else. This is all a bit arbitrary and should be unified.
- ...there's much more cruft.
In a way, this PR just provides yet another way of dumping values and generators. Some of the other existing ways should be consolidated or killed.
Added option --ir to test-runner to activate (and test) IR dumping.
Pull Request resolved: https://github.com/facebook/prepack/pull/2493
Differential Revision: D9560883
Pulled By: NTillmann
fbshipit-source-id: 70920c8e1b4139c69329d8f5ab6e6267a35f058b
Summary:
Release note: Speed up simplifier by using an implication cache per path branch
The realm's path conditions is now a class instances and an explicit tree, along with caches for expressions that have already been checked for true/false using Path.implies on the current set of path conditions.
The AbstractValueImplicationCounter is still there as flag, to be renamed later. It is no longer used as a global k-limit, but enables k-limits on the cost of constructing a new set of path conditions. When React is the target, path conditions are not re-specialized. This leads to a very nice performance win for the large React internal test.
A number of tweaks to the simplifier were needed to get tests to pass. Some of these were borrowed from PR #2460.
Pull Request resolved: https://github.com/facebook/prepack/pull/2494
Reviewed By: trueadm
Differential Revision: D9554820
Pulled By: hermanventer
fbshipit-source-id: 5fdc550499975fe11c0c954b9502cd4eeab2bafe
Summary:
Release notes: Refactor of joined descriptors. Expect a slight performance regression. Will fatal in more cases that we would previously silently possibly generate the wrong code.
Currently we have three types of property descriptors. 1) Descriptors used by internal slots. 2) Normal concrete descriptors. 3) Abstract joined descriptors.
These are all typed as arbitrary an inexact object where all the fields are optional. That means that essentially any object with any typo can be assigned to a descriptor.
We are also not forced to deal with the joined descriptor case. Almost everywhere we assume that joined descriptors are really just a generic descriptor object which doesn't have any attributes on it.
There are so many small bugs related to this so I figured it's time to start dealing with it.
This PR turns this inexact object into nominally typed PropertyDescriptor, AbstractJoinedDescriptor and InternalSlotDescriptor. Essentially the same model as values.
Thanks to this Flow forces me to ensure that I've covered all of these cases. I've dealt with it in the cases I figured I could figure it out and where it was necessary such as the serializer/join/widen. In all other cases where we don't know, I ensure that we throw a fatal error instead of assuming that a joined descriptor is an empty descriptor.
Pull Request resolved: https://github.com/facebook/prepack/pull/2473
Differential Revision: D9526419
Pulled By: sebmarkbage
fbshipit-source-id: 1d3556b2d4608c02ba2570651f4e6a765fa0eea6
Summary:
Release notes: None
- Fixing type of `quasis` in Babel and as field
- Instead of storing callTemplate as a derived function, store instead the source string (working towards having a human-readable generator intermediate format)
Pull Request resolved: https://github.com/facebook/prepack/pull/2490
Differential Revision: D9540696
Pulled By: NTillmann
fbshipit-source-id: d7ab8c68857d4b8b4e584894edb3781dce3db2b2
Summary:
Release notes: None
Instead of storing some obscure function in OperationDescriptorData, this makes it store the template source.
This brings us closer to the generator tree being an abstract intermediate format, and simplifies the code.
Pull Request resolved: https://github.com/facebook/prepack/pull/2491
Differential Revision: D9540484
Pulled By: NTillmann
fbshipit-source-id: 7ae86488c708c4e8e08490987437f18de9a70bd0
Summary:
gaearon found a regression to the cases I fixed in #2255. The following code:
```js
function fn1(arg) {
if (arg.foo()) {
if (arg.bar()) {
return 42;
}
}
}
function fn2(arg) {
if (arg.foo()) {
if (arg.bar()) {
return 1;
}
} else {
return 2;
}
}
if (global.__optimize) {
__optimize(fn1);
__optimize(fn2);
}
```
Now compiles to:
```js
var fn1, fn2;
(function() {
var _$4 = this;
var _0 = function(arg) {
var _$0 = arg.foo();
if (_$0) {
var _$1 = arg.bar();
}
if (_$0) {
var _$1 = arg.bar(); // <----------------------------- `arg.bar()` is redeclared.
}
return _$0 ? (_$1 ? 42 : void 0) : void 0;
};
var _8 = function(arg) {
var _$2 = arg.foo();
var _$3 = arg.bar(); // <------------------------------- `arg.bar()` should be inside `if (_$2)`
return _$2 ? (_$3 ? 1 : void 0) : 2;
};
_$4.fn1 = _0;
_$4.fn2 = _8;
}.call(this));
```
After looking through the commits, I found that #2274 regressed this case. After reverting that PR I found that these cases were fixed again, but interestingly the test added in that PR also passed after I reverted the change.
I’m opening this PR with the failing tests so hermanventer can take a look. I haven’t looked too deeply into this case, so I’m probably missing something important. Maybe some race condition between the landing of #2255 and #2274?
Pull Request resolved: https://github.com/facebook/prepack/pull/2288
Differential Revision: D9540424
Pulled By: calebmer
fbshipit-source-id: 3ef03068cb575617d64d73fdc1f9431188effdda
Summary:
Release notes: none
This unblocks an issue found in https://github.com/facebook/prepack/pull/2494.
After looking into https://github.com/facebook/prepack/pull/2494, which showed that without that PR, some conditions with `&&` weren't being passed correctly to the React reconciler to be properly inlined. With this PR applied however, this issue no longer occurs but we do run into another problem.
The React reconciler will attempt to evaluate, resolve and inline all paths. Typically, if a "value" that a React component returned wasn't that of a valid type (string, ReactElement, null and some other objects) we would throw an `ExpectedBailOut`. This turned out to break logic in common use-case though: `&&` conditions.
Take the below example though:
```js
function Child() {
return <div>This should be inlined</div>;
}
function App(props) {
var a = props.x ? null : function() {};
return a && <Child />;
}
```
In this case with, the React reconciler will see `function () {}` as one of the paths of the `&&` condition and try and inline all paths and hit the fact you can't return `function () {}` and throw the `ExpectedBailOut`.
The realism is that the React reconciler in Prepack is being too smart here. It doesn't need to be concerned with the fact that the valid might not be valid. If the result is not valid, then the user will hit a runtime issue with React with their original input too. Ultimately, all we need to do is return the valid.
There are three tests attached to this PR. Only `simple-24` is a direct test for the changes in this PR, `simple-22` and `simple-23` are regression tests for when https://github.com/facebook/prepack/pull/2494 is applied.
Pull Request resolved: https://github.com/facebook/prepack/pull/2498
Differential Revision: D9539852
Pulled By: trueadm
fbshipit-source-id: c5bba2b9315d7f2af5fdeb612f56e739a7aa2c23
