the actual "fix" in this change is the chunk that moves
`let x = self.consume()` to after the option dance that results in
the `notify_chan` in TaskBuilder.try()
the rest is cleanup/sense-making of what some of this code is doing (I'm
looking at you, future_result)
This can trigger a crash because we assume we
can supply null ptrs and undefined values for
values of those types, as we should be treated
them as zero-size.
Interestingly, this crash only shows up (atm)
in non-optimized builds. Therefore, I added
a -Z no-opt flag so that the new test
(capture_nil) can specify that it should not
run with optimizations enabled.
This was too restrictive. We need to check the number of ty params,
and that the bounds are equal, but otherwise require_same_types does the job.
Closes#2611
But note that default methods still don't work cross-crate (see #2794) --
this just makes it so that when a method is missing in a cross-crate impl,
the right error message gets printed.
Closes#3344
This should address the valgrind failure that @elliotslaughter
was seeing, though I am not sure why the bots / test continued
to pass, since this is precisely the condition this test was looking
for!
Safe points are exported in a per-module list via the crate map. A C
runtime call walks the crate map at startup and aggregates the list of
safe points for the program.
Currently the GC doesn't actually deallocate memory on malloc and
free. Adding the GC at this stage is primarily of testing value.
The GC does attempt to clean up exchange heap and stack-allocated
resource on failure.
A result of this patch is that the user now needs to be careful about
what code they write in destructors, because the GC and/or failure
cleanup may need to call destructors. Specifically, calls to malloc
are considered unsafe and may result in infinite loops or segfaults.