This change maps MuJS interface types to MuIL, including property and
method declarations. The mapping is fairly straightforward, and similar
to the existing class lowering, except for some minor AST differences in
the TypeScript representations. We emit interface types as classes with
the interface bit set, and all method declarations being abstract.
This change improves the line-by-line error reports when a test fails,
both in the diagnostics messages and AST tree baseline comparisons.
Previously, the test would fail at the first occurrence of a mismatch,
often with little information about the context. In this change, the
test will now fail with a full dump of the comparison.
For instance, here is the before for a test failure in a new case I'm adding:
AssertionError: Expected tree line #1 to match
+ expected - actual
- "name": "iface_1",
+ "name": "class_1",
In comparison, here is what the test failure looks like now:
AssertionError: Expected trees to match; 6 did not
+ expected - actual
-1: "name": "iface_1",
-10: "I": {
-14: "ident": "I",
-19: "column": 10
-23: "column": 11
-29: "interface": true,
+1: "name": "class_1",
+10: "C": {
+14: "ident": "C",
+19: "column": 6
+23: "column": 7
+29: "abstract": false,
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.
There were a few places where we didn't propagage source locations
correctly. This fixes that. Part of the issue was we didn't have
good helper methods to propagate "ranges" (e.g., a sequence of
statements or expressions), so this change adds those.
This change also establishes a new naming convention; the addLocation*
methods adds a newly allocated location based on translating a TypeScript
AST node, whereas the copyLocation* methods copy them directly from
other MuIL nodes. Thus, there are now four methods: addLocation,
addLocationRange, copyLocation, and copyLocationRange.
This change adds a new AST node kind to represent "new" expressions.
Originally I had thought we could simply represent these as calls to
a constructor, however, there is a sizeable semantic difference and so
it's better for this node kind to be distinct; for example, we will
most likely permit allocation of objects without explicit constructors.
In addition, I've added a "complex" scenario test, which is just a
Point class. It has a constructor, two properties, and an instance
method that performs arithmetic and allocates a new instance. It works!
This uses explicit type coercions when creating interface types with
object literals. This helps the compiler catch some additional errors,
such as mistyped property names (of which we had two instances, for
load location expressions ("key" vs "name")).
The old way we shared code between VariableLike and FunctionLike cases --
across module, class, and locals -- was slightly confusing, and required a
lot of dynamic object property copying, etc. This change is a little bit
easier on the eyes, correctly handles variable initializers more uniformly,
and prepares us for class properties (the next change to land).
This change maps MuJS access expressions to the MuPack/MuIL forms.
As part of this, I've changed the representation in the AST. It doesn't
make much sense to distinguish between variable, member, and function access.
Instead, all accesses will be uniform, and will evaluate to the proper type.
This change introduces basic class lowering into MuPack/MuIL. There are
a handful of things not yet supported (like extends/implements and properties),
however, simple methods and variables are supported.
This change introduces lowering for function definitions and parameters.
This includes a few tests for both exported and unexported module-level
function definitions. Class members will come shortly...
This change properly retains and emits the desired accessibility for
module properties, based on whether a property has been exported or not.
It also updates the existing export property test baseline and adds
another one for unexported module properties.
This change uses paths relative to the compilation root context path,
so that they aren't absolute and therefore aren't tied to a specific
machine. This fixesmarapongo/mu#42, and cleans up our test baselines.
Per marapongo/mu#42, this change shortens module names to be more "Mu-like"
and to reflect the relative module paths. There is still awkwardness if there
are any "up and over" references, i.e. using "..", but this handles the 95%
case. We still don't mark entrypoints, but this gets us one step closer.
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 changes the test harness to do a line-by-line comparison, rather than
full text comparison, for AST checking. This is a bit nicer to diagnose, because
failures will specifically point out the line that deviates, rather than dumping
the (possibly huge) string containing the full expected/actual ASTs.
This adds a baseline for the empty module test, and it passes.
Unfortunately, because module names are absolute file paths, this
baseline file has my machine's specific path embedded in it. I want
to lock these in so they are passing as I make progress. Sometime
later this morning I'll fix the module naming to be "relative" and
more Mu-friendly, and this issue will go away.
For now we will use the module's fileName as its name. This matches
the ECMAScript semantics, however, we will eventually want to do a pass
to normalize these names into more "Mu-friendly" module names.
This changes the way we represent identifiers slightly, and then lowers
the TypeScript representation to them. Prior to this change, identifiers
could be naked strings; after this change, identifiers are always first class
AST nodes -- so they can carry location information -- and tokens assume the
role of naked strings. This means some definition maps must now be keyed by
tokens and also means that some AST node properties that used to carry just
naked strings needed to be updated to carry first class AST nodes.
This is an initial cut at implementing variable declaration lowering.
The lowering is slightly different for module properties and local variables,
since the former requires that code go into the module initializer, while the
latter can mostly happen "inline" as the local variable is bound.
There are some incomplete parts in here -- like lowering type names -- that
are dependent on a few upcoming changes.
This change translates MuJS modules and their various top-level statements
into the corresponding MuPack/MuIL metadata. Notably, to ensure static analyzability,
MuIL doesn't permit arbitrary class, function, etc. definitions as statements. Instead,
they must occur at the top-level, and be recognized as such statically. That's the bulk
of this change. The individual nodes aren't necessarily mapped yet, however.
The way ECMAScript and Python work is that each file maps to a module. There
isn't really an "official" notion of a submodule; instead, directories on the
import path are conventionally used as submodule names. Aggregate submodules
can be achieved by convention with re-exports in ECMAScript, however this is an
informal notion. We could keep the current structured submodule notion and require
that all languages map to it, however, it is just as easy to have a flat list of
top-level modules indexed by name. This change rearranges the AST accordingly.
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 adds two expressions we will need to support many type test patterns.
IsInst simply checks an expression for castability to a target type; it evaluates
to a boolean.
TypeOf fetches the runtime type of a given expression and evaluates to its name.
Right now, this is just a string token, rather than some richer RTTI object.
This is mostly boilerplate, mapping the following AST kinds: IfStatement,
ReturnStatement, ThrowStatement, Block, EmptyStatement, ExpressionStatement,
and LabeledStatement.
The stacks.md document used to describe the metadata format. Now that we've
moved away from the old model of YAML + Go templates, and created the MuPack/MuIL
format, this document needed to be overhauled.
It's pretty bare bones now, however it will eventually evolve into a document
describing how the Mu abstractions map down onto MuPack/MuIL concepts. For example,
it describes how subclassing mu.Stack creates a "stack", even though at the MuPack/MuIL
level it's just any old subclass.
