Use the compiler to drive as many language services as possible

[josephjclark]

For example, can we use the compiler to detect State and lazy state references and top level operations

This requires a big compiler change

• instead of detecting and transforming structures, we split the compiler into two phases
• Phase 1 traverses the AST, detects key structures (operation, lazy state reference) and annotates the AST
• Phase 2 finds the annotated nodes and transforms them, just as it does today.

If we have this compiler architecture, then VSC only needs to run phase 1, not phase 2, and we can re-use the logic.

Can we swap out VSC's in built compiler and use our own? Rather than parsing twice? The dream implementation is that we would control the first ast compilation that VSC does, annotate extra stuff, and then pass the esprima API syntax tree down to VSC.

Alternatively, we extract the esprima tree from VSC and pass that into the compiler (rather than compiling ourselves with acorn).

Either of these solutions prevents a duplication of work. But it's not essential!

[doc-han]

Other things the compiler needs to do

1. Provide hover information for tokens that aren't adaptor functions
2. Assist in function signature. That's knowing the nth argument of a function & erroring when a function is provided more than required arguments
3. Warn users when they don't return state in a job.

[josephjclark]

Yeah I was thinking about this late at night: we have been thinking about logging warnings in the compiler for various things, but it feels like it's too late to do it at runtime.

But if we're using the compiler for static analysis, we can generate those warnings and report them back to the editor at build time. Should work great in VSC and Monaco!