Testi ting an and Evol olving g TypeScr Script De Declaration - - PowerPoint PPT Presentation

▶
testi ting an and evol olving g typescr script de
SMART_READER_LITE
LIVE PREVIEW

Testi ting an and Evol olving g TypeScr Script De Declaration - - PowerPoint PPT Presentation

Nov 28, 2023 617 likes •851 views

Testi ting an and Evol olving g TypeScr Script De Declaration on Files with P Progr ogram An Analysi sis s Erik Krogh Kristensen joint work with Anders Mller C ENTER FOR A DVANCED S OFTWARE A NALYSIS http://casa.au.dk/

slide-1
SLIDE 1

Testi ting an and Evol

  • lving

g TypeScr Script De Declaration

  • n Files

with P Progr

  • gram An

Analysi sis s

Erik Krogh Kristensen

joint work with Anders Møller Π CENTER FOR ADVANCED SOFTWARE ANALYSIS

http://casa.au.dk/

slide-2
SLIDE 2
  • Microsoft’s extension of JavaScript
  • Adds optional types
  • optional type declarations
  • classes, modules, ...
  • Static type checking
  • Compiled to JavaScript

2

slide-3
SLIDE 3

Using JavaScript libraries in TypeScript applications

  • Contains declarations for >4000 libraries
  • Hand-written, lots of bugs

⇒ mislead type checking and code completion!

3

slide-4
SLIDE 4

4

An example: p2.js

JavaScript library implementation TypeScript type declaration

4

function Constraint(...) { /** * Equations to be solved in * this constraint * * @property equations * @type {Array} */ this.equations = []; ... } ... class Constraint { constructor(...); equeations: Equation[]; ... }

slide-5
SLIDE 5

Another example: d3.js

JavaScript library implementation TypeScript type declaration

5

slide-6
SLIDE 6

Three research challenges

  • 1. How to detect mismatches between

library implementations and type declarations?

  • 2. How to infer type declarations for libraries?
  • 3. How to evolve type declarations,

as the library code evolves?

6

slide-7
SLIDE 7

Three research challenges

  • 1. How to detect mismatches between

library implementations and type declarations?

  • 2. How to infer type declarations for libraries?
  • 3. How to evolve type declarations,

as the library code evolves?

7

  • 1. How to detect mismatches between

library implementations and type declarations?

Exi xisting approaches are re limited ed

  • TSCheck (Feldthaus and Møller 2014): Based on static analysis, imprecise
  • TPD (Williams et al. 2017): Require existing unit tests
slide-8
SLIDE 8

TST TSTest – feedback-directed random testing

Based on automated testing

(Randoop: Feedback-directed random test generation, Pacheco, Lahiri, Ernst, and Ball, ICSE'07)

How to adapt Randoop-style testing from Java to TypeScript?

(structural typing, higher-order functions, generics, …)

8

[Type Test Scripts for TypeScript Testing, Kristensen & Møller, OOPSLA 2017]

JavaScript library implementation TypeScript type declaration

var Store = { makeItem: function(n) { return { print: function() { return n; } } } } declare var Store: { makeItem(n: number): Item } interface Item { print(): string }

slide-9
SLIDE 9

JavaScript implementation TypeScript declaration Type Test Script JavaScript interpreter Mismatches

TST TSTest – how it works

slide-10
SLIDE 10

TSTest – experimental results

  • 54 benchmarks
  • Running each type test script for 10 seconds results in

2804 found mismatches (many with same root cause)

  • Mismatches found in 49/54 benchmarks
  • Finds many mismatches that are missed by

previous work (TSCheck)

10

slide-11
SLIDE 11

Are the mismatches benign or serious?

error 63 strict nulls 47 benign 14

  • Sampled 124 random mismatches
  • No false positives
slide-12
SLIDE 12

Benign gn?

e xp e xpor t

  • r t f u

f unc nc t i o t i on n bi ndAc t i onCr e a t or s <A e xt e nd e xt e nds s Ac t i onCr e a t or <a ny a ny>> ( a c t i onCr e a t or : A) : A; f un f unc t i c t i on

  • n bi ndAc t i onCr e a t or s ( c r e a t or s ) {

va r va r r e s ul t = {}; f or f or ( va r va r ke y i n i n c r e a t or s ) { va r va r c r e a t or = c r e a t or s [ ke y] ; i f i f ( t ype o t ype of c r e a t or === ' f unc ' f unc t i o t i on' n' ) { r e s ul t [ ke y] = bi ndAc t i onCr e a t or ( c r e a t or , di s pa t c h) ; } } r e t ur n r e t ur n r e s ul t ; }

redux.d.ts redux.js

slide-13
SLIDE 13

Three research challenges

  • 1. How to detect mismatches between

library implementations and type declarations?

  • 2. How to infer type declarations for libraries?
  • 3. How to evolve type declarations,

as the library code evolves?

13

slide-14
SLIDE 14

The Holy Grail

Infer the same declaration that an expert human would write ?

f unc t i on f unc t i on ge t ( obj , k) { r e t ur n r e t ur n obj [ k] ; }

f unc t c t i on ge t <T>( obj : T[ ] , k: num be r ) : T f unc t c t i on ge t <T>( obj : {[ i : s t r i n i ng] : T}, k: s t r i ng) : T f unc t c t i on ge t <T, K e xt e nds ke yof T>( obj : T, k: K) : T[ K] ; f unc t c t i on ge t ( obj : num be r [ ] , k: num be r ) : num be r

14

slide-15
SLIDE 15

TS TSInfer – a declaration file inference tool [FASE 2017]

  • Dynamically analyze library initialization

Snapshot of heap after loading

  • Extract modules, classes, fields
  • Static analysis to infer function signatures

15

slide-16
SLIDE 16

Static analysis in TSInfer

  • TSInfer must infer parameter types and return types!

Also for methods that are never called within the library

  • Unification-based too imprecise
  • Instead: upper-bound and lower-bound à la Pottier

A framework for type inference with subtyping, François Pottier, ICFP’98

  • Unsound, flow-insensitive, context-insensitive
  • Analyze entire library once

To get information about how the library uses itself

16

slide-17
SLIDE 17

Upper-bound and lower-bound dataflow analysis à la Pottier

  • Forward dataflow analysis (lower-bound)

“what values may flow in?”

  • Backward dataflow analysis (upper-bound)

“how may the values be used?”

17

x = ne w C( ) ; . . . f oo( x) ; f unc t i on f oo( a ) { . . . b = a . ne xt ; . . . }

Both kinds of information give useful hints to types, when analyzing libraries without the applications!

slide-18
SLIDE 18

e xpor

  • r t c l a s

a s s Spr i t e e xt e n e nds PI XI . Cont a i ne r { c ons t r uc t or ( t e xt ur e : PI XI . Te xt ur e ) ; s t a t i c f r om Fr a m e : ( f r a m e I d: s t r i n i ng | num be be r ) => PI XI . Spr i t e ; s t a t i c f r om I m a ge : ( i m a ge I d: s t r i n i ng, c r os s or i gi n: a ny, s c a l e M

  • de : a ny) => PI XI . Spr i t e ;

_he i ght : num be be r ; _wi dt h: num be be r ; a nc hor : PI XI . Poi nt ; bl e ndM

  • de : num

be r ;

  • nTe xt ur e Upda t e : ( ) => voi d;

s e t Te xt ur e : ( t e xt ur e : PI XI . Te xt ur e ) => voi d; s ha de r : a ny; t e xt ur e : PI XI . Te xt ur e ; t i nt : num be r ; }

Example output from running TSInfer on PixiJS 2.2

Our goal is to get close to what a human would write

?: boolean ?: number

private private PIXI.Shader private

18

slide-19
SLIDE 19

Three research challenges

  • 1. How to detect mismatches between

library implementations and type declarations?

  • 2. How to infer type declarations for libraries?
  • 3. How to evolve type declarations,

as the library code evolves?

19

slide-20
SLIDE 20

TSEv Evolve – a tool for fixing out-of-date declaration files

  • ld.d.ts
  • ld.js

new.js TSInfer new.gen.d.ts Compare List of changes TSInfer

  • ld.gen.d.ts

Filter Filtered list of changes

First naive approach Our approach

20

Too many false positives, due to

  • imprecise static analysis
  • intentional mismatches
slide-21
SLIDE 21

TSEvolve: pull requests

  • Updated type declaration files for 6 different libraries
  • From 30 to 516 lines patched
  • No prior experience with the libraries
  • Done in about 1 day of work

21

slide-22
SLIDE 22

Conclusion

  • Optional types have become popular
  • Need to interact with untyped libraries
  • Static/dynamic program analysis to the rescue!
  • TSTest [OOPSLA 2017]
  • TSInfer & TSEvolve [FASE 2017]

Π CENTER FOR ADVANCED SOFTWARE ANALYSIS

http://casa.au.dk/

22