This adds parser support and most of the machinery for
auto x = 10, y = 20;
However, the above still goes wrong somewhere in typestate, causing
the state checker to believe only the last variable in the list is
initialized after the statement.
Tim, if you have a moment, could you go over the changes to the tstate
code in this patch and see where I'm going wrong?
Multi-var-decls without the typestate extension
Add a loop
Probably more should be moved or split off into other files. My algorithm
was something along the lines of: move the contexts and their transitive
dependencies along with some functions to work with them. I stopped when
I was going to have to start pulling glue generation, which really
should go into a trans_glue file.
This essentially starts the bootstrapping one step earlier by building
the stdlib from source using the stage0 compiler and then using that
stdlib to build the stage1 compiler. (Instead of starting by building
the stage1 compiler and then building a stdlib with it).
This means we should now be able to add features to the stdlib and use
them in the compiler without having to do a snapshot. (On the flip
side, this means that we now need to do a snapshot if we want to use a
new language feature in the stdlib, but that doesn't really seem too
burdensome (we already need to snapshot if we want to use a new
language feature in the compiler)).
We're trying to get closer to doing correct move semantics for channel
operations. This involves a lot of cleanup (such as removing the
unused sched parameter from rust_vec constructor) and making
circular_buffer kernel_owned.
Added tagging for memory allocations. This means we give a string tag
to everything we allocate. If we leak something and TRACK_ALLOCATIONS
is enabled, then it's much easier now to tell exactly what is leaking.
I'm not sure if this is because of changes to glue generation in the
last few days while I've been working on other things, or if it's a
side effect of the improvements I made to typechecking for anonymous
objects, or something else, but I guess I'll take it!
Closes issue #543.