bors [Thu, 2 May 2013 16:18:37 +0000 (09:18 -0700)]
auto merge of #6182 : huonw/rust/core-str-opts, r=nikomatsakis
This adds #[inline] to many very common string routines (e.g. `len`).
It also rewrites `repeat` to not use `+=` and make it O(n) rather than O(n^2), and also concat/connect(_slices) to reduce the overhead of reallocations, and constantly `set_len`ing (etc) in `push_str`. (The added complexity might not be worth the 20% speedup though.)
bors [Thu, 2 May 2013 06:09:36 +0000 (23:09 -0700)]
auto merge of #6175 : Aatch/rust/red-zone-warn, r=sanxiyn
This has happened to two people trying to get Rust working on other platforms. Since it won't compile either way, make a nicer message for it (which will also point them straight to the correct file).
bors [Thu, 2 May 2013 04:00:39 +0000 (21:00 -0700)]
auto merge of #6151 : bjz/rust/local-variable-cleanup, r=brson
I have noticed these comments scattered across the codebase. They appear to be vestigial Emacs formatting settings and they don't appear in newer files. For the sake of consistency it's probably best to remove them.
this could probably use expansion - it just uses all of the default
options, which is usually what we want, but not always. maybe add a
separate function that takes more options?
only tested on linux/x86_64, but i got the values for other platforms
from their system header files.
no bindings for win32, because win32 doesn't include glob.h.
also, glob() takes a callback for error handling, but i'm just making
this a *c_void for now, since i don't know how to represent c calling
back into rust (if that's even currently possible).
bors [Wed, 1 May 2013 16:18:59 +0000 (09:18 -0700)]
auto merge of #6148 : erickt/rust/remove-drop, r=pcwalton
The drop block has been deprecated for quite some time. This patch series removes support for parsing it and all the related machinery that made drop work.
As a side feature of all this, I also added the ability to annote fields in structs. This allows comments to be properly associated with an individual field. However, I didn't update `rustdoc` to integrate these comment blocks into the documentation it generates.
bors [Wed, 1 May 2013 08:51:35 +0000 (01:51 -0700)]
auto merge of #6147 : bjz/rust/numeric-traits, r=brson
After much discussion on IRC and #4819, we have decided to revert to the old naming of the `/` operator. This does not change its behavior. In making this change, we also have had to rename some of the methods in the `Integer` trait. Here is a list of the methods that have changed:
bors [Wed, 1 May 2013 07:57:35 +0000 (00:57 -0700)]
auto merge of #6144 : catamorphism/rust/mkdir_recursive-breakage, r=thestinger
r? @brson or @thestinger : Added a change_dir_locked function to os, and use it in the
mkdir_recursive tests so that the tests don't clobber each other's
directory changes.
bors [Wed, 1 May 2013 01:36:45 +0000 (18:36 -0700)]
auto merge of #6105 : Aatch/rust/linker-improv, r=pcwalton
Adds two extra flags: `--linker` which takes extra flags to pass to the linker, can be used multiple times and `--print-link-args` which prints out linker arguments. Currently `--print-link-args` needs execution to get past translation to get the `LinkMeta` data.
I haven't done tests or updated any extra documentation yet, so this pull request is currently here for review.
auto merge of #6134 : jld/rust/issue-6117, r=catamorphism
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
Jed Davis [Tue, 30 Apr 2013 19:05:06 +0000 (12:05 -0700)]
Reverse accidental src/llvm reversion in 876483dcf, and add test.
The test is reduced from a doc test, but making it separate ensures that
(1) unrelated changes to the docs won't leave this case uncovered, and
(2) the nature of any future failures will be more obvious to whoever
sees the tree on fire as a result.
Jed Davis [Tue, 30 Apr 2013 18:36:22 +0000 (11:36 -0700)]
The null case of a nullable-poiner enum might not be nullary.
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
John Clements [Thu, 18 Apr 2013 20:44:49 +0000 (13:44 -0700)]
This test case is obsolete for two reasons
First, it refers to a feature (trait bounds on type parameters) that's
apparently no longer in the language. Second, if I understand the issue
correctly, it should never have been a "run-pass" test because it was
supposed to fail.
auto merge of #6108 : gifnksm/rust/bigint-shift-bug, r=brson
`std::bigint` contains the following code.
```rust
borrow = *elem << (uint::bits - n_bits);
```
The code above contains a bug that the value of the right operand of the shift operator exceeds the size of the left operand,
because sizeof(*elem) == 32, and 0 <= n_bits < 32 in 64bit architecture.
If `--opt-level` option is not given to rustc, the code above runs as if the right operand is `(uint::bits - n_bits) % 32`,
but if --opt-level is given, `borrow` is always zero.
I wonder why this bug is not catched in the libstd's testsuite (I try the `rustc --test --opt-level=2 bigint.rs` before fixing the bug,
but the unittest passes normally.)
This pull request also removes the implicit vector copies in `bigint.rs`.
auto merge of #6073 : huonw/rust/core-rust-isaac, r=pcwalton
This replaces the wrapper around the runtime RNG with a pure Rust implementation of the same algorithm. This is much faster (up to 5x), and is hopefully safer.
There is still (a little) room for optimisation: testing by summing 100,000,000 random `u32`s indicates this is about ~~40-50%~~ 10% slower than the pure C implementation (running as standalone executable, not in the runtime).
(Only 6d50d55 is part of this PR, the first two are from #6058, but are required for the rt rng to be correct to compare against in the tests.)
Huon Wilson [Fri, 26 Apr 2013 13:23:49 +0000 (23:23 +1000)]
core: a pure Rust implementation of the ISAAC RNG.
This replaces the wrapper around the runtime RNG with a pure Rust
implementation of the same algorithm. This is faster (up to 5x), and
is hopefully safer.
There is still much room for optimisation: testing by summing 100,000,000
random `u32`s indicates this is about 40-50% slower than the pure C
implementation (running as standalone executable, not in the runtime).