| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Understand 'pkgid' in stage0. As a bonus, the snapshot now contains now metadata
(now that those changes have landed), and the snapshot download is half as large
as it used to be!
|
|
See commits for details.
|
|
|
|
raw}::copy_memory.
Slices carry their length with them, so we can just use that
information.
|
|
|
|
This makes sure we always run benchmarks even if they are predicted to
take a long time, so that we have some non-zero time to display
(although the error bars may be huge for particularly slow benchmarks).
Fixes #9532.
|
|
These got swept up in the great privatizing of 2013.
|
|
Several of the members of `extra::stats::Summary` were calculated and tested, but not exposed externally. This change exposes all of the members.
|
|
|
|
This makes sure we always run benchmarks even if they are predicted to
take a long time, so that we have some non-zero time to display
(although the error bars may be huge for particularly slow benchmarks).
Fixes #9532.
|
|
These got swept up in the great privatizing of 2013.
|
|
|
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
34 uses of `Cell` remain.
r? @alexcrichton
|
|
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes #10188, #8523.
|
|
I could have done this by making `Arc` use RAII, but this is too
involved for now.
|
|
34 uses of `Cell` remain.
|
|
|
|
There's an open issue ([Issue #4988](https://github.com/mozilla/rust/issues/4988?source=cc)) for adding an LRU Cache to the standard library. I'm new to this so I hope I didn't miss anything I'm supposed to do.
|
|
|
|
This reverts commit c54427ddfbbab41a39d14f2b1dc4f080cbc2d41b.
Leave the #[ignores] in that were added to rustpkg tests.
Conflicts:
src/librustc/driver/driver.rs
src/librustc/metadata/creader.rs
|
|
|
|
This function had type &[u8] -> ~str, i.e. it allocates a string
internally, even though the non-allocating version that take &[u8] ->
&str and ~[u8] -> ~str are all that is necessary in most circumstances.
|
|
|
|
This registers new snapshots after the landing of #10528, and then goes on to tweak the build process to build a monolithic `rustc` binary for use in future snapshots. This mainly involved dropping the dynamic dependency on `librustllvm`, so that's now built as a static library (with a dynamically generated rust file listing LLVM dependencies).
This currently doesn't actually make the snapshot any smaller (24MB => 23MB), but I noticed that the executable has 11MB of metadata so once progress is made on #10740 we should have a much smaller snapshot.
There's not really a super-compelling reason to distribute just a binary because we have all the infrastructure for dealing with a directory structure, but to me it seems "more correct" that a snapshot compiler is just a `rustc` binary.
|
|
|
|
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 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
|
|
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 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
|
|
|
|
Updated doc comments further, following suggestions from huonw in PR
#10752.
|
|
|
|
|
|
|
|
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.
|
|
|
|
This PR does some small modernizations to the json library. First is to remove the `@` boxes, second is to rename the constructors to `new`.
|
|
|
|
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nikomatsakis/rust/issue-8624-borrowck-overly-permissive, r=pnkfelix
See #8624 for details.
r? @pnkfelix
|
|
|
