No abstract

In this paper we present the design and implementation of Flow, a fast and precise type checker for JavaScript that is used by thousands of developers on millions of lines of code at Facebook every day. Flow uses sophisticated type inference to understand common JavaScript idioms precisely. This helps it find non-trivial bugs in code and provide code intelligence to editors without requiring significant rewriting or annotations from the developer. We formalize an important fragment of Flow's analysis and prove its soundness. Furthermore, Flow uses aggressive parallelization and incrementalization to deliver near-instantaneous response times. This helps it avoid introducing any latency in the usual edit-refresh cycle of rapid JavaScript development. We describe the algorithms and systems infrastructure that we built to scale Flow's analysis.

We present Refined TypeScript (RSC), a lightweight refinement type system for TypeScript, that enables static verification of higher-order, imperative programs. We develop a formal core of RSC that delineates the interaction between refinement types and mutability. Next, we extend the core to account for the imperative and dynamic features of TypeScript. Finally, we evaluate RSC on a set of real world benchmarks, including parts of the Octane benchmarks, D3, Transducers, and the TypeScript compiler.We convert arr[ ] to get(arr, ) which is checked under environment Γ head defined as arr : {ν : T[] | 0 < len(ν)} yielding the subtyping obligation:The VC is proved valid by an SMT solver [24], verifying subtyping, and hence, the array access' safety. Path Sensitivity is obtained by adding branch conditions into the typing environment. Consider: function head ( a: number []) : number { if ( < a . length ) return head ( a ) ; return ; }Recall that head should only be invoked with non-empty arrays. The call to head above occurs under Γ head defined as: a : number[], 0 < len(a) i.e. which has the binder for the formal a, and the guard predicate established by the branch condition. Thus, the call to head yields the obligation:yielding the valid VC: 0 < len(a) ⇒ (ν = a ⇒ 0 < len(ν)) Polymorphic, Higher Order Functions Next, let us assume that reduce has the type T reduce described in (1), and see how to verify the array safety of minIndex (Figure 1). The challenge here is to precisely track which values can flow into min (used to index into a), which is tricky since those values are actually produced inside reduce.Types make it easy to track such flows: we need only determine the instantiation of the polymorphic type variables of reduce at this call site inside minIndex. The type of the ∆ ::= · | e → δ | s → δ | .

Deadlocks can have devastating effects in systems code. We have developed a type and effect system that provably avoids them and in this paper we present a tool that uses a sound static analysis to instrument multithreaded C programs and then links these programs with a run-time system that avoids possible deadlocks. In contrast to most other purely static tools for deadlock freedom, our tool does not insist that programs adhere to a strict lock acquisition order or use lock primitives in a block-structured way, thus it is appropriate for systems code and OS applications. We also report some very promising benchmark results which show that all possible deadlocks can automatically be avoided with only a small run-time overhead. More importantly, this is done without having to modify the original source program by altering the order of resource acquisition operations or by adding annotations.

No abstract