bors [Sun, 22 Dec 2013 05:01:51 +0000 (21:01 -0800)]
auto merge of #11110 : alexcrichton/rust/attempt-to-fix-osx-segfaulting, r=brson
Upon inspecting the core dumps, they're all segfaulting at the same instruction
with the same value in a register that looks fishy. It appears to be indexing
into an array with a -1 index and then getting some weird overflow and dying.
I have attempted to fix this as part of
alexcrichton/libuv@fd5308383c575472edb2163d823dc6670bf59609,
but I am unsure of whether this is the actual cause of the problem, so I am not
going to upstream it just yet. I have a fairly high confidence that this is
indeed the problem, but I want to make sure that the bots to segfault all over
the place before upstreaming.
Alex Crichton [Sun, 22 Dec 2013 04:17:23 +0000 (20:17 -0800)]
Attempt to fix the segfaulting osx bots
Upon inspecting the core dumps, they're all segfaulting at the same instruction
with the same value in a register that looks fishy. It appears to be indexing
into an array with a -1 index and then getting some weird overflow and dying.
I have attempted to fix this as part of
alexcrichton/libuv@fd5308383c575472edb2163d823dc6670bf59609,
but I am unsure of whether this is the actual cause of the problem, so I am not
going to upstream it just yet. I have a fairly high confidence that this is
indeed the problem, but I want to make sure that the bots to segfault all over
the place before upstreaming.
bors [Sat, 21 Dec 2013 04:01:41 +0000 (20:01 -0800)]
auto merge of #10930 : DaGenix/rust/remove-unnecessary-fields, r=alexcrichton
3 minor clean-ups now that #9629 is fixed:
* Update MutChunkIter to remove the ```remainder``` that existed just to allow the size_hint() method to be implemented. This is no longer necessary since we can just access the length of the slice directly.
* Update MutSplitIterator to address the FIXME in its size_hint() method. This method was only partially implemented due to the issue. Also, implement a minor optimization in the case that its the last iteration.
* Update ByRef iterator to implement the size_hint() method.
I noticed that MutSplitIterator returns an empty slice if called on an empty slice. I don't know if this is intended or not, but I left the ```finished``` field in-place to preserve this behavior.
Palmer Cox [Thu, 12 Dec 2013 01:51:22 +0000 (20:51 -0500)]
Update next() and size_hint() for MutSpliterIterator
Update the next() method to just return self.v in the case that we've reached
the last element that the iterator will yield. This produces equivalent
behavior as before, but without the cost of updating the field.
Update the size_hint() method to return a better hint now that #9629 is fixed.
bors [Fri, 20 Dec 2013 23:21:33 +0000 (15:21 -0800)]
auto merge of #11077 : alexcrichton/rust/crate-id, r=cmr
Right now the --crate-id and related flags are all process *after* the entire
crate is parsed. This is less than desirable when used with makefiles because it
means that just to learn the output name of the crate you have to parse the
entire crate (unnecessary).
This commit changes the behavior to lift the handling of these flags much sooner
in the compilation process. This allows us to not have to parse the entire crate
and only have to worry about parsing the crate attributes themselves. The
related methods have all been updated to take an array of attributes rather than
a crate.
Additionally, this ceases duplication of the "what output are we producing"
logic in order to correctly handle things in the case of --test.
Finally, this adds tests for all of this functionality to ensure that it does
not regress.
bors [Fri, 20 Dec 2013 17:11:33 +0000 (09:11 -0800)]
auto merge of #11075 : alexcrichton/rust/issue-10392, r=brson
We decided in the 12/10/13 weekly meeting that trailing commas should be
accepted pretty much anywhere. They are currently not allowed in struct
patterns, and this commit adds support for that.
Alex Crichton [Thu, 19 Dec 2013 20:23:39 +0000 (12:23 -0800)]
rustc: Improve crate id extraction
Right now the --crate-id and related flags are all process *after* the entire
crate is parsed. This is less than desirable when used with makefiles because it
means that just to learn the output name of the crate you have to parse the
entire crate (unnecessary).
This commit changes the behavior to lift the handling of these flags much sooner
in the compilation process. This allows us to not have to parse the entire crate
and only have to worry about parsing the crate attributes themselves. The
related methods have all been updated to take an array of attributes rather than
a crate.
Additionally, this ceases duplication of the "what output are we producing"
logic in order to correctly handle things in the case of --test.
Finally, this adds tests for all of this functionality to ensure that it does
not regress.
bors [Fri, 20 Dec 2013 10:06:34 +0000 (02:06 -0800)]
auto merge of #11017 : alexcrichton/rust/faster-read, r=thestinger
We were previously reading metadata via `ar p`, but as learned from rustdoc
awhile back, spawning a process to do something is pretty slow. Turns out LLVM
has an Archive class to read archives, but it cannot write archives.
This commits adds bindings to the read-only version of the LLVM archive class
(with a new type that only has a read() method), and then it uses this class
when reading the metadata out of rlibs. When you put this in tandem of not
compressing the metadata, reading the metadata is 4x faster than it used to be
The timings I got for reading metadata from the respective libraries was:
In order to always take advantage of these faster metadata read-times, I sort
the files in filesearch based on whether they have an rlib extension or not
(prefer all rlib files first).
Overall, this halved the compile time for a `fn main() {}` crate from 0.185s to
0.095s on my system (when preferring dynamic linking). Reading metadata is still
the slowest pass of the compiler at 0.035s, but it's getting pretty close to
linking at 0.021s! The next best optimization is to just not copy the metadata
from LLVM because that's the most expensive part of reading metadata right now.
Alex Crichton [Tue, 17 Dec 2013 04:58:21 +0000 (20:58 -0800)]
rustc: Optimize reading metadata by 4x
We were previously reading metadata via `ar p`, but as learned from rustdoc
awhile back, spawning a process to do something is pretty slow. Turns out LLVM
has an Archive class to read archives, but it cannot write archives.
This commits adds bindings to the read-only version of the LLVM archive class
(with a new type that only has a read() method), and then it uses this class
when reading the metadata out of rlibs. When you put this in tandem of not
compressing the metadata, reading the metadata is 4x faster than it used to be
The timings I got for reading metadata from the respective libraries was:
In order to always take advantage of these faster metadata read-times, I sort
the files in filesearch based on whether they have an rlib extension or not
(prefer all rlib files first).
Overall, this halved the compile time for a `fn main() {}` crate from 0.185s to
0.095s on my system (when preferring dynamic linking). Reading metadata is still
the slowest pass of the compiler at 0.035s, but it's getting pretty close to
linking at 0.021s! The next best optimization is to just not copy the metadata
from LLVM because that's the most expensive part of reading metadata right now.
bors [Fri, 20 Dec 2013 01:11:40 +0000 (17:11 -0800)]
auto merge of #11057 : alexcrichton/rust/no-at-in-ebml, r=pcwalton
Now that the metadata is an owned value with a lifetime of a borrowed byte
slice, it's possible to have future optimizations where the metadata doesn't
need to be copied around (very expensive operation).
Alex Crichton [Wed, 18 Dec 2013 22:10:28 +0000 (14:10 -0800)]
Purge @-boxes from the reading half of EBML
Now that the metadata is an owned value with a lifetime of a borrowed byte
slice, it's possible to have future optimizations where the metadata doesn't
need to be copied around (very expensive operation).
bors [Thu, 19 Dec 2013 20:01:59 +0000 (12:01 -0800)]
auto merge of #11072 : chris-morgan/rust/ctags-tweaks, r=cmr
Anchoring the keyword as the first non-whitespace on a line may mean
that the occasional genuine-but-unconventionally-formatted tag is
missed, but it avoids a large number of false positives.
I changed the type descriptive texts about a bit too. That part's purely
cosmetic.
I also changed the ignored file list to use a filename matching the make
rule, `TAGS.vi` instead of `TAGS.vim`.
Alex Crichton [Thu, 19 Dec 2013 17:21:05 +0000 (09:21 -0800)]
Accept trailing commas in struct patterns
We decided in the 12/10/13 weekly meeting that trailing commas should be
accepted pretty much anywhere. They are currently not allowed in struct
patterns, and this commit adds support for that.
Chris Morgan [Thu, 19 Dec 2013 14:31:38 +0000 (01:31 +1100)]
Remove many false positives from the ctags results
Anchoring the keyword as the first non-whitespace on a line may mean
that the occasional genuine-but-unconventionally-formatted tag is
missed, but it avoids a large number of false positives.
I changed the type descriptive texts about a bit too. That part's purely
cosmetic.
I also changed the ignored file list to use a filename matching the make
rule, `TAGS.vi` instead of `TAGS.vim`.
Huon Wilson [Thu, 19 Dec 2013 02:56:53 +0000 (13:56 +1100)]
std::vec: use some unsafe code to optimise `remove`.
Also, add `.remove_opt` and replace `.unshift` with `.remove(0)`. The
code size reduction seem to compensate for not having the optimised
special cases.
This makes the included benchmark more than 3 times faster.
bors [Thu, 19 Dec 2013 08:16:35 +0000 (00:16 -0800)]
auto merge of #11038 : alexcrichton/rust/fix-osx-leak, r=cmr
I haven't landed this fix upstream just yet, but it's opened as
joyent/libuv#1048. For now, I've locally merged it into my fork, and I've
upgraded our repo to point to the new revision.
Alex Crichton [Tue, 17 Dec 2013 21:12:36 +0000 (13:12 -0800)]
Upgrade libuv to fix a leak on OSX
I haven't landed this fix upstream just yet, but it's opened as
joyent/libuv#1048. For now, I've locally merged it into my fork, and I've
upgraded our repo to point to the new revision.
Huon Wilson [Thu, 19 Dec 2013 02:23:37 +0000 (13:23 +1100)]
std::vec: replace .insert with a small amount of unsafe code.
This makes the included benchmark more than 3 times faster. Also,
`.unshift(x)` is now faster as `.insert(0, x)` which can reuse the
allocation if necessary.
bors [Thu, 19 Dec 2013 02:41:35 +0000 (18:41 -0800)]
auto merge of #10927 : g3xzh/rust/sum_bugfix, r=huonw
`[1e20, 1.0, -1e20].sum()` returns `0.0`. This happens because during
the summation, `1.0` is too small relative to `1e20`, making it
negligible.
I have tried Kahan summation but it hasn't fixed the problem.
Therefore, I've used Python's `fsum()` implementation.
For more details, read:
www.cs.cmu.edu/~quake-papers/robust-arithmetic.ps
https://github.com/mozilla/rust/issues/10851
bors [Thu, 19 Dec 2013 01:11:42 +0000 (17:11 -0800)]
auto merge of #11029 : huonw/rust/rm-vec-as-buf, r=cmr
For `str.as_mut_buf`, un-closure-ification is achieved by outright removal (see commit message). The others are replaced by `.as_ptr`, `.as_mut_ptr` and `.len`
g3xzh [Wed, 11 Dec 2013 23:57:13 +0000 (01:57 +0200)]
Fix `sum()` accuracy
`[1e20, 1.0, -1e20].sum()` returns `0.0`. This happens because during
the summation, `1.0` is too small relative to `1e20`, making it
negligible.
I have tried Kahan summation but it hasn't fixed the problem.
Therefore, I've used Python's `fsum()` implementation with some
help from Jason Fager and Huon Wilson.
For more details, read:
www.cs.cmu.edu/~quake-papers/robust-arithmetic.ps
Moreover, benchmark and unit tests were added.
Note: `Status.sum` is still not fully fixed. It doesn't handle
NaNs, infinities and overflow correctly. See issue 11059:
https://github.com/mozilla/rust/issues/11059
`.as_mut_buf` was used exactly once, in `.push_char` which could be
written in a simpler way, using the `&mut ~[u8]` that it already
retrieved. In the rare situation when someone really needs
`.as_mut_buf`-like functionality (getting a `*mut u8`), they can go via
`str::raw::as_owned_vec`.
bors [Wed, 18 Dec 2013 16:36:36 +0000 (08:36 -0800)]
auto merge of #11033 : michaelwoerister/rust/byvalself, r=pcwalton
As the title says. The trans changes will lead to an auxiliary alloca being created that allows debug info to track the `self` argument. This alloca is only created in debug builds however. Otherwise very little had to be done after I managed to navigate to some degree the jungle that is self-argument handling `:P`
bors [Wed, 18 Dec 2013 11:36:33 +0000 (03:36 -0800)]
auto merge of #11025 : ezyang/rust/reword-second-borrow, r=cmr
When a borrow occurs twice illegally, Rust will label the other borrow
as the "second borrow". This is quite confusing, as the "second borrow"
usually happened before the flagged barrow (e.g. as far as dataflow
is concerned, the first borrow is OK, the second borrow is illegal.)
This patch renames "second borrow" to "previous borrow", to make the
spatial relationship between the two borrows clearer.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
bors [Wed, 18 Dec 2013 05:31:47 +0000 (21:31 -0800)]
auto merge of #11019 : alexcrichton/rust/issue-10545, r=pcwalton
This code in resolve accidentally forced all types with an impl to become
public. This fixes it by default inheriting the privacy of what was previously
there and then becoming `true` if nothing else exits.
These were defined for each other but never *used* anywhere. They are
all trivial and so removal will have negligible effect upon anyone.
`Either` has fallen out of favour (and its implementation of these
traits of dubious semantics), `Option<T>` → `Result<T, ()>` was never
really useful and `Result<T, E>` → `Option<T>` should now be done with
`Result.ok()` (mirrored with `Result.err()` for even more usefulness).
In summary, there's really no point in any of these remaining.
bors [Tue, 17 Dec 2013 19:36:42 +0000 (11:36 -0800)]
auto merge of #10979 : alexcrichton/rust/less-bc, r=cmr
By performing this logic very late in the build process, it ended up leading to
bugs like those found in #10973 where certain stages of the build process
expected a particular output format which didn't end up being the case. In order
to fix this, the build output generation is moved very early in the build
process to the absolute first thing in phase 2.
Alex Crichton [Tue, 17 Dec 2013 07:32:37 +0000 (23:32 -0800)]
Don't allow impls to force public types
This code in resolve accidentally forced all types with an impl to become
public. This fixes it by default inheriting the privacy of what was previously
there and then becoming `true` if nothing else exits.
bors [Tue, 17 Dec 2013 17:01:58 +0000 (09:01 -0800)]
auto merge of #11030 : cmr/rust/rustdoc_on_fire, r=metajack
By returning the items to process and storing them in a queue, we were losing
the context that was setup for that item during the recursion. This is an easy
fix, rather than hoisting out the state that it needs.
Corey Richardson [Tue, 17 Dec 2013 16:19:14 +0000 (11:19 -0500)]
Fix rustdoc HTML rendering
By returning the items to process and storing them in a queue, we were losing
the context that was setup for that item during the recursion. This is an easy
fix, rather than hoisting out the state that it needs.
bors [Tue, 17 Dec 2013 15:41:40 +0000 (07:41 -0800)]
auto merge of #10972 : metajack/rust/pkgid-with-name, r=alexcrichton
This change extends the pkgid attribute to allow of explicit crate names, instead of always inferring them based on the path. This means that if your GitHub repo is called `rust-foo`, you can have your pkgid set your library name to `foo`. You'd do this with a pkgid attribute like `github.com/somewhere/rust-foo#foo:1.0`.
Jack Moffitt [Sun, 15 Dec 2013 02:58:07 +0000 (19:58 -0700)]
Change pkgid parser to allow overriding the inferred crate name.
Previously the a pkgid of `foo/rust-bar#1.0` implied a crate name of
`rust-bar` and didn't allow this to be overridden. Now you can override the
inferred crate name with `foo/rust-bar#bar:1.0`.
Edward Z. Yang [Tue, 17 Dec 2013 12:55:33 +0000 (20:55 +0800)]
s/Second borrow/Previous borrow/ in error messages.
When a borrow occurs twice illegally, Rust will label the other borrow
as the "second borrow". This is quite confusing, as the "second borrow"
usually happened before the flagged borrow (e.g. as far as dataflow
is concerned, the first borrow is OK, the second borrow is illegal.)
This patch renames "second borrow" to "previous borrow", to make the
spatial relationship between the two borrows clearer.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
bors [Tue, 17 Dec 2013 11:51:40 +0000 (03:51 -0800)]
auto merge of #10996 : huonw/rust/more-vec-raw, r=cmr
The removal of the aliasing &mut[] and &[] from `shift_opt` also comes with its simplification.
The above also allows the use of `copy_nonoverlapping_memory` in `[].copy_memory` (I did an audit of each use of `.copy_memory` and `std::vec::bytes::copy_memory`, and I believe none of them are called with arguments can ever alias). This changes requires that `unsafe` code using `copy_memory` **needs** to respect the aliasing rules of `&mut[]`.
bors [Tue, 17 Dec 2013 10:31:55 +0000 (02:31 -0800)]
auto merge of #10990 : ktt3ja/rust/method-stability, r=huonw
If it's a trait method, this checks the stability attribute of the
method inside the trait definition. Otherwise, it checks the method
implementation itself.
bors [Tue, 17 Dec 2013 09:16:43 +0000 (01:16 -0800)]
auto merge of #10830 : alexcrichton/rust/spsc-queue, r=brson
This pull request completely rewrites std::comm and all associated users. Some major bullet points
* Everything now works natively
* oneshots have been removed
* shared ports have been removed
* try_recv no longer blocks (recv_opt blocks)
* constructors are now Chan::new and SharedChan::new
* failure is propagated on send
* stream channels are 3x faster
I have acquired the following measurements on this patch. I compared against Go, but remember that Go's channels are fundamentally different than ours in that sends are by-default blocking. This means that it's not really a totally fair comparison, but it's good to see ballpark numbers for anyway
* oneshot - N times, create a "oneshot channel", send on it, then receive on it (no task spawning)
* stream - N times, send from one task to another task, wait for both to complete
* shared1 - create N threads, each of which sends M times, and a port receives N*M times.
The rows are as follows:
* `std` - the current libstd implementation (before this pull request)
* `my` - this pull request's implementation (in M:N mode)
* `native` - this pull request's implementation (in 1:1 mode)
* `goN` - go's implementation with GOMAXPROCS=N. The only relevant value is 8 (I had 8 cores on this machine)
* `goN-X` - go's implementation where the channels in question were created with buffers of size `X` to behave more similarly to rust's channels.
projects / rust.git / log