I've renamed `MutableVector::mut_split(at)` to `MutableVector::mut_split_at(at)` to be coherent with ImmutableVector. As specified in the commit log, The `size_hint` method is not optimal because of #9629.
This method is the mutable version of ImmutableVector::split. It is
a DoubleEndedIterator, making mut_rsplit irrelevent. The size_hint
method is not optimal because of #9629.
At the same time, clarify *split* iterator doc.
* Don't flag any address_insignificant statics as reachable because the whole
point of the address_insignificant optimization is that the static is not
reachable. Additionally, there's no need for it to be reachable because LLVM
optimizes it away.
* Be sure to not leak external node ids into our reachable set, this can
spuriously cause local items to be considered reachable if the node ids just
happen to line up
The section on closure types was missing, so I added one. I'm new to Rust, so there are probably important things to say about closure types that I'm missing here.
I tested the example with the latest Rust nightly.
This wasn't uncovered during testing because the librustrt is available locally
in the build directory (and it needs to be for all the tests to link against it
as well).
Closes#10765
Controversial change: make the constructors safe, but instead mark the
setters and getters as unsafe. This follows the tradition that construction
of *T is safe, but the access is unsafe instead.
Generally use more modern constructs (such as using `CVec::new()` as
constructor and move to more method usage).
Potentially controversial changes:
* change `get()` to return a reference instead of cloning
* remove `set()`, add `get_mut()` instead
* add an `unwrap()` method that destroys the CVec without running any
associated destructor
This includes documentation for all the previous changes done to linking
in #10582. Additionally, this brings the list of feature-gates up-to-date with
the currently recognized list of features.
This wasn't uncovered during testing because the librustrt is available locally
in the build directory (and it needs to be for all the tests to link against it
as well).
Closes#10765
Turns out that we only want to install the target rlibs, not the host rlibs.
I had it backwards the first time, then mixed up the second time, but this time
should get it right.
There's no need for host rlib files because none of them are needed at runtime.
This is inspired by a mystifying linker failure when using `pkg-config` to
generate the linker args: `pkg-config` produces output that ends in a
space, thus resulting in an empty linker argument.
Also added some updates to the concerning error messages that helped
spotting this bug.
This is inspired by a mystifying linker failure when using `pkg-config` to
generate the linker args: `pkg-config` produces output that ends in a
space, thus resulting in an empty linker argument.
Also added some updates to the concerning error messages that helped
spotting this bug.
Turns out that we only want to install the target rlibs, not the host rlibs.
I had it backwards the first time, then mixed up the second time, but this time
should get it right.
There's no need for host rlib files because none of them are needed at runtime.
Stop relying on a malloc error to indicate failure and instead use an
explicit check. Also ensure that the value is dropped at the correct
time (e.g. that the if statement is translated into `{ expr }` instead
of `expr`).
**Note**: I only tested on top of my #10670 PR, size reductions come from both change sets.
With this, [more enums are shrinked](https://gist.github.com/eddyb/08fef0dfc6ff54e890bc), the most significant one being `ast_node`, from 104 bytes (master) to 96 (#10670) and now to 32 bytes.
My own testcase requires **200MB** less when compiling (not including the other **200MB** gained in #10670), and rustc-stage2 is down by about **130MB**.
I believe there is more to gain by fiddling with the enums' layouts.
Stop relying on a malloc error to indicate failure and instead use an
explicit check. Also ensure that the value is dropped at the correct
time (e.g. that the if statement is translated into `{ expr }` instead
of `expr`).
mut_chunks() returns an iterator that produces mutable slices. This is the mutable version of the existing chunks() method on the ImmutableVector trait.
EDIT: This uses only safe code now.
PREVIOUSLY:
I tried to get this working with safe code only, but I couldn't figure out how to make that work. Before #8624, the exact same code worked without the need for the transmute() call. With that fix and without the transmute() call, the compiler complains about the call to mut_slice(). I think the issue is that the mutable slice that is returned will live longer than the self parameter since the self parameter doesn't have an explicit lifetime. However, that is the way that the Iterator trait defines the next() method. I'm sure there is a good reason for that, although I don't quite understand why. Anyway, I think the interface is safe, since the MutChunkIter will only hand out non-overlapping pointers and there is no way to get it to hand out the same pointer twice.
BufferedWriter::inner flushes before returning the underlying writer.
BufferedWriter::write no longer flushes the underlying writer.
LineBufferedWriter::write flushes up to the *last* newline in the input
string, not the first.
