This change adds a set of true diagnostics constructs, underneath the
new `diag` module.
This includes projecting Mu-specific errors as real diagnostics in a
way that is unified with TypeScript errors. The only difference, of
course, is that Mu errors tend to happen in later passes. But this is
not necessarily always the case.
As part of this, I've rearranged the compiler passes to present a
simpler interface to users of the compiler API (currently just the CLI
and test harness, but it's just a library, so anybody can use it).
Namely, there are three phases:
1. Compilation is the overall process of taking an input path
and driving the entire compilation process, yielding a set of
diagnostics and, ideally, a final MuPackage at the end of it.
2. Script compilation is the process of driving the front-end
compiler -- in this case TypeScript -- yielding a set of Mu
diagnostics and, if that went well, the script's AST.
3. Transformation is the process of taking the script output and
lowering it into the final MuPackage form.
Most people will deal with 1, blissfully unaware of the presence of
independent 2 and 3 phases. We choose to keep them distinct for
white box testing and for future scenarios we have yet to envision.
This change adds discovery of Mu metadata in the form of a Mu.json file.
This allows us to eliminate the "TODO" in place of a real package name in
the output ASTs, so our baselines are adjusted accordingly. This is part
of marapongo/mu#42 -- implementation of real module and package names.
This adds a new test harness that will be used to run baseline-style
tests. Each subdirectory underneath tests/output will be interpreted as
a test case, each of which can contain an optional `messages.txt` file
which will be compared as the expected output against the compiler's error
and warning messages, and/or an optional `Mu.out.json` file which will be
compared as the expected output against the compiler's output tree.
There's just a single "empty" test case for now. I will start getting in
the habit of checking in a companion test for each AST kind we lower.
This change refactors a few things:
* Eliminate the `mujs.il` package; instead, introduce `mujs.ast`.
* Split `mujs.ast` into many different files, to organize things a
little more cleanly into expressions, nodes, sources, and statements.
* Move most definitions from the `mujs.pack` package into `mujs.ast`,
into the definitions file. This ensures that all definitions are true
AST nodes, meaning they will preserve source location information.
This change adds a simple compiler module that hosts TypeScript and
compiles a program. The compile function takes a path and optional options
data structure; the path can be one of three things: 1) a path to a single `*.ts`
file, in which case it, and it alone, is compiled; 2) a path to a `tsconfig.json`
file, in which case it is loaded, parsed, and used to drive compilation just
like the `tsc` command line driver; or 3) a path to a directory containing a
`tsconfig.json` file, in which case it is discovered and used just like #2.
There is also a new command line driver that just blindly passes arguments to
this compiler API, and prints the results. Next up, this will begin lowering and
transforming the resulting TypeScript AST to MuPack and MuIL.
Note that I've reorganized the source code slightly, so that instead of just
`src/*`, we now have `lib/*` for the library, `cmd/*` for any CLI drivers, and,
soon, `test/*` for test cases.
This is an initial implementation of the MuIL AST.
The AST has been intentionally pared back to the bare essentials, leaving the
task of lowering to the higher level MetaMu compilers. For example, there is
only a single conditional statement, a single looping construct, etc.
It is in the MuJS compiler package so that we can begin lowering TypeScript
ASTs to this format and serializing them. We will need separate Go projections
of these shapes in order to deserialize and evaluate programs to produce MuGL
from within the runtime/evaluation engine.
I'm sure the shape of these things will need to change -- and there are a
handful of open questions -- however, this is a start...
