Under valgrind on 64->32 cross compiles the dynamic linker is emitting
some error messages on stderr, which interferes with the tests that
are checking stderr.
This commit fixes#7022 - I've added an additional check to ensure that
stk is not null before dereferencing it to get it's next element,
assigning NULL if it is itself NULL.
This commit fixes#7022 - I've added an additional check to ensure that
stk is not null before dereferencing it to get it's next element,
assigning NULL if it is itself NULL.
r? @jld or @graydon
The calculation looks right to me, but perhaps one of you two can double check. You two seem like you are doing the most recent work in this sort of area.
Fix for #6575. In the trans phase, rustc emits code for a function parameter that goes completely unused in the event the return type of the function in question happens to be an immediate.
This patch modifies rustc & parts of rustrt to ensure that the vestigial parameter is no longer present in compiled code.
r?
This is all of my scheduler work on #4419 from the last 3 weeks or so. I've had a few failed pull requests so far but I think the problems are ironed out.
* TCP
* The beginnings of runtime embedding APIs
* Porting various corners of core to be compatible with both schedulers
* libuv timer bindings
* Further refinement of I/O error handling, including a new, incomplete, `read_error` condition
* Incomplete refactoring to make tasks work without coroutines and user-space scheduling
* Implementations of Reader/Writer extension methods
* Implementations of the most important part of core::comm
I'm particularly happy with how easy the [comm types on top of the scheduler](https://github.com/brson/rust/blob/io-upstream/src/libcore/rt/comm.rs). Note that these implementations do not use pipes. If anything here needs careful review though it's this code.
This branch passes 95% of the run-pass tests (with `TESTARGS=--newrt`)
In the next week I'll probably spend some time adding preliminary multithreading and seeing how close we are to removing the old runtime.
It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.
