The old method of specifying a default module for a package was using
a bit on the module definition itself. The new method is to specify the
module name as part of the package definition itself.
The new approach makes more sense for a couple reasons. 1) it doesn't
make sense to have more than one "default" for a given package, and yet
the old model didn't prevent this; the new one prevents it by construction.
2) The defaultness of a module is really an aspect of the package, not the
module, who is generally unaware of the package containing it.
The other reason is that I'm auditing the code for nondeterministic map
enumerations, and this came up, which simply pushed me over the edge.
The prior module binding logic was naive. It turns out that, because of inter-module
references within the same package, the order of binding certain modules and its members
within a package matters. This leads to a more Java/C#/JavaScript/etc. multi-pass model,
versus a classical single-pass C/C++ model (which requires forward declarations).
To do this, we bind things in this order within a package:
* First, we add an entry for each module. It is largely empty, but at least names resolve.
* Second, we bind all imports. Since all modules are known, all inter-module tokens resolve.
* Next, we can bind class symbols. Note that we must do this prior to module properties,
methods, and exports, since they might be referenced and need to exist first. As before,
we do not yet bind function bodies, since those can reference anything.
* Now we bind all module "members", meaning any module scoped properties and methods. Again,
we do not bind function bodies just yet. This is just a symbolic binding step.
* Next, we can finally bind exports. Because exports may reference any members, all of the
above must have been done first. But all possibly exported symbols are now resolved.
* Finally, we can bind function bodies.
This adds a `mu verify` command that simply runs the verification
pass against a MuPackage and its MuIL. This is handy for compiler
authors to verify that the right stuff is getting emitted.
This change restructures how MuJS selects the format and output a
bit, so that simply running `mujs -f yaml` will output a default
`Mupack.yaml` in the current directory.
This change stops printing the AST to output after compilation. It's
a little confusing and, especially as Mu test programs are getting larger,
staring at 1,000s of lines of JSON whiz by is losing it's fun.
By default, the compiler saves output into Mupack.json. This can be
overridden with the --out switch (-o for short). Both JSON and YAML files
are supported (as are unrecognized extensions, which get JSON by default).
Another switch --format (-f for short) is supported to explicitly specify
the output format. A special -out of "-" means "print to stdoutput", so
for instance, running `mujs -o=- -f=yaml` will print YAML to the console.
This change doesn't attempt to transform the resulting AST if there
were any compiler errors. The old code erroneously proceeded in cases
where errors occurred but an AST was actually produced, leading to
possible assertions and other unexpected conditions.
I just introduced the examples/aws/ directory yesterday to hold some
of our basic AWS examples, as I expect us to start accumulating more
of them. So this just moves ec2instance underneath that directory.
We should probably think about further reorganizing these (e.g., into
demos/, scenarios/, etc.), ass we accumulate more examples.
I've had a few times where I missed errors/warnings whizzing by alongside
other spew. Although this was probably technically a "waste" of 10 minutes,
it actually would have saved me at least 10 in the past. So, there you go.
This adds map tests for ES6-style maps encoded in MuPack/MuIL.
It also fixes one simple bug, where we should not populate the
compiler options with TypeScript defaults *unless* they are (a)
missing from the arguments and (b) not discovered from a tsconfig
file. Otherwise, we will rewrite overrides with the defaults.
This change just adds a clean target to the MuJS compiler's package
file. If you rename tests, the old files stick around inside of bin/,
possibly causing superfluous test failures. A clean does the trick.
This change adds support for generating array type tokens from MuJS.
Previously, we'd try to load up the Array type's associate MuPackage,
which is TypeScript's standard library; and then we'd error out
because, of course, it doesn't have one. Now we recognize references
to it (and ES6-style Map<K, V>) to generate the correct tokens.
This includes a bunch of new array tests.
This nixes the old *.mu files from the AWS MuPackage (when Mull was a thing),
and the nasty YAML files (when Go templates in YAML was a thing...(?!)). The
TypeScript variants remain, however, which is what we'll use going forward.
To prevent shell expansion of the glob "**", we must quote the path.
This fixes a bug that @lukehoban ran into last night on Windows, where
globbing wasn't be expanded the same way; ironically, it seems to have
been expanded the way we actually wanted it to...but obviously we want
globbing to work well on *NIX filesystems even moreso than Windows.
This also fies a couple missed lint errors in our tests that are
revealed as a result.
This stuff is still evolving -- and I've put it on pause to make progress
on graph generation -- but I had these edits in my enlistment and didn't
want to lose them.
This change stops digging into the "new" expression and instead uses
the TypeScript-assigned type (based on its bound signature). The result
is that expressions of the form
import * as aws from "aws";
let vm = new aws.ec2.VM(...);
now typecheck and emit fully resolved type tokens for the constructed types.
This is pretty worthless, but will help me debug some issues locally.
Eventually we want MuGL to be fully serializable, including the option
to emit DOT files.
