trans::trans_lval will now autobind if the given expression was the
name of a generic functions. Those callees (trans_call and trans_bind)
that are interested in the generics information call trans_lval_gen
now.
The first is that the memory_region destructor would complain there is
still an outstanding allocation. This is because circular_buffer from
rust_chan wasn't refing its task, so the task was being destructed too
soon.
The second was where the program could deadlock while joining a
task. The target task would die in the time between checking whether
the task should block and then actually blocking. The fix is to use
the target task's lock.
Ports and channels have been moved to the kernel pool, since they've
been known to outlive their associated task. This probably isn't the
right thing to do, the life cycle needs fixed instead.
Some refactorying in memory_region.cpp. Added a helper function to
increment and decrement the allocation counter. This makes it easier
to switch between atomic and non-atomic increments. Using atomic
increments for now, although this still does not fix the problem.
Previously, we were creating both a normal vtable entry and a
forwarding function for overriding methods, when they should have just
gotten a vtable entry. This patch fixes that.
As a preparation for implementing the temporary-move optimization for
argument passing. The optimization itself isn't in yet, since it
mysteriously corrupts memory.
This adds support for dropping cleanups for temporary values when they
are moved somewhere else. It then adds wraps most copy operations
(return, put in data structure, box, etc) in a way that will fall back
to a move when it is safe.
This saves a lot of taking/dropping, shaving over a megabyte off the
stage2/rustc binary size.
In some cases, most notably function returns, we could detect that the
returned value is a local variable, and can thus be safely moved even
though it is not a temporary. This will require putting some more
information in lvals.
I did not yet handle function arguments, since the logic for passing
them looked too convoluted to touch. I'll probably try that in the
near future, since it's bound to be a big win.
The duplication of upcalls is due to the fact that the runtime is
shared between stage0/rustc and stage1/rustc. Once snapshots are
updated, they should be de-duplicated.