Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Compiler assumptions

Christopher Blappert edited this page Jul 11, 2018 · 11 revisions

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.
Clone this wiki locally