* 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.
mut_chunks() returns an iterator that produces mutable slices. This is the
mutable version of the existing chunks() method on the ImmutableVector trait.
CFG_BUILD_DIR, CFG_LLVM_SRC_DIR and CFG_SRC_DIR all have trailing
slashes, by definition, so this is correct.
(This is purely cosmetic; the doubled slash is ignored by all the tools we're using.)
This adds support to link to OSX frameworks via the new link attribute when
using `kind = "framework"`. It is a compiler error to request linkage to a
framework when the target is not macos because other platforms don't support
frameworks.
Closes#2023
In this series of commits, I've implemented static linking for rust. The scheme I implemented was the same as my [mailing list post](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html).
The commits have more details to the nitty gritty of what went on. I've rebased this on top of my native mutex pull request (#10479), but I imagine that it will land before this lands, I just wanted to pre-emptively get all the rebase conflicts out of the way (becuase this is reorganizing building librustrt as well).
Some contentious points I want to make sure are all good:
* I've added more "compiler chooses a default" behavior than I would like, I want to make sure that this is all very clearly outlined in the code, and if not I would like to remove behavior or make it clearer.
* I want to make sure that the new "fancy suite" tests are ok (using make/python instead of another rust crate)
If we do indeed pursue this, I would be more than willing to write up a document describing how linking in rust works. I believe that this behavior should be very understandable, and the compiler should never hinder someone just because linking is a little fuzzy.
