Compiler assumptions

Introduction

To allow for better optimizations in the general case, the compiler makes various assumptions. This is an attempt to document these assumptions.

Terminology

A function is "pure" if...

• it doesn't mutate any pre-existing observable state, and
• any particular call to the function may be omitted or duplicated; in other words, the function must be idempotent and deterministic.

Notes:

• A pure function may inspect declarative bindings and object properties.
• A pure function may mutate newly created objects.
• A pure function may return an existing or a newly created object.
• A pure function may throw an exception, which is really just a special form of a result.

General

• Names of functions might not be preserved.
• The field order of prepacked objects might have changed.
• .toString() on functions is likely to produce slightly different output.

"Pure scope" assumptions

When dealing with abstract values in "pure scope" evaluation, Prepack makes the following assumptions.

• Property reads are assumed to be side effect free. If a property is backed by a getter, then the getter must be a pure function.
• Property writes backed by setters, and calls to abstract functions may only mutate state that is reachable from the call arguments; in particular, they may not mutate built-in intrinsic objects. We say that reachable objects "leak".
• Property descriptors of leaked objects may not be inspected.
• toString, valueOf, and instanceof are assumed to be pure.

React compiler has the additional assumption that your React code follows these rules

"Optimized function" assumptions

• All built-in intrinsic objects are exactly in the same configuration as they were at the end of the global code execution.