We promoted some exciting RFCs to FCP this week:
RFC #1398: Custom allocator traits. These are traits
intended to eventually be used to customize e.g. what allocator
Vecuses. (In collaboration with libs team.)
RFC #1513: Stabilize implementing panics as aborts. This RFC
adds various options to allow the “end crate” (e.g., the
application) to specify that panics ought to be compiled as aborts,
rather than initiating unwinding. This is useful for applications
that would prefer to crash the process, since supporting unwinding
causes more code generation and can inhibit some optimizations.
- The end-user model we are aiming towards with this RFC is that panics mean “abort and let somebody else handle it” – in the case of unwinding, that “somebody else” may be another thread, but in the case of aborting, that “somebody else” is another process.
Several RFCs enter their final comment period this week:
FCP PR #1398:
Allocators, take III
- Proposes a comprehensive API for describing and using allocators, with the
intent that types like
HashMapcan ultimately support custom allocators.
- Proposes a comprehensive API for describing and using allocators, with the intent that types like
- FCP PR #1529: rfc 1291: Add libutil to scope of libc crate on Linux
- FCP PR #1552: Add a contains method to VecDeque and LinkedList
As usual, we covered several PRs that needed team decisions:
Decreasing code bloat when deriving Clone for Copy data
- We want to do this, but had some reservations about the initially-proposed approach.
Changing AtomicBool size to 1 byte
- We want to reach a decision here while resolving open RFCs on the topic.
Placement for Vec
- We want to add these APIs, but are wary of doing so in an ad hoc way without any conventions (and thereby de facto stabilizing poor conventions); blocked on a quick conventions RFC.
Heap allocation guarantee
- We are fine with making this promise, but would like to avoid a lot of ad hoc promise-making along these lines, in favor of a more comprehensive look at representation promises.
Add augmented assignment to time times
We did some maintenance on the nursery:
- Making progress on rustc-serialize without breakage
- We need to consolidate the time libraries in the ecosystem, and in particular
make the external time libraries compatible with the new
std::timetypes. Ideally, this would happen by deprecating the
timecrate in favor of
chrono, and making
std-compatible. The libs team is working with the relevant authors to make progress here.
- Dealing with
std::os::rawtypes and their interaction.
- Not fully resolved – ongoing discussion is here.
Now that rustbuild can bootstrap new hosts for the compiler, there are now nightly compilers for five new platforms, with Cargo following quite soon! These artifacts are all lightly tested, however, and some broader testing would be much appreciated!
If you’ve got a new host target you’d like to see builds of rustc and Cargo for, ping
acrichtoon IRC (or @alexcrichton on GitHub) and we’ll try to get it set up!
The built-in test runner now has a flag to have quieter output when running tests (one dot per test instead of one line)
A new test suite has been added to the compiler which should help detect regression on a broader range of the ecosystem when landing any change to rust-lang/rust
A number of instances of seemingly infinite recursion in Cargo have been solved through a more optimized traversal of the dependency space when resolving dependencies.
Cargo’s style for printing errors has changed to be much more readable.
Cargo will now read the
RUSTFLAGSenvironment variable to pass flags to the compiler for all crates as part of a compilation.
Cargo should now correctly handle concurrent invocations and ensure that global state is not corrupted and builds complete.
The multirust-rs project has now grown the initial rustup implementation which will soon be deployed!
See the table of new builds here!