bors [Sun, 2 Feb 2014 06:31:26 +0000 (22:31 -0800)]
auto merge of #11948 : huonw/rust/show, r=alexcrichton
- renames `Default` to `Show`
- introduces some hidden `std::fmt::secret_...` functions, designed to work-around the lack of UFCS (with UFCS they can be replaced by referencing the trait methods directly) because I'm going to convert the traits to have methods rather than static functions, since `#[deriving]` works much better with true methods.
I'm blocked on a snapshot after this. (I could probably do a large number of `#[cfg]`s, but I can work on other things in the meantime.)
bors [Sat, 1 Feb 2014 19:16:24 +0000 (11:16 -0800)]
auto merge of #11974 : huonw/rust/no-at-vec, r=pcwalton
This removes @[] from the parser as well as much of the handling of it (and `@str`) from the compiler as I can find.
I've just rebased @pcwalton's (already reviewed) `@str` removal (and fixed the problems in a separate commit); the only new work is the trailing commits with my authorship.
bors [Sat, 1 Feb 2014 18:01:25 +0000 (10:01 -0800)]
auto merge of #11973 : dotdash/rust/u64_to_bytes, r=huonw
LLVM fails to properly optimize the shifts used to convert the source
value to the right endianess. The resulting assembly copies the value
to the stack one byte at a time even when there's no conversion required
(e.g. u64_to_le_bytes on a little endian machine).
Instead of doing the conversion ourselves using shifts, we can use the
existing intrinsics to perform the endianess conversion and then
transmute the value to get a fixed vector of its bytes.
Before:
````
test be_i8 ... bench: 21442 ns/iter (+/- 70)
test be_i16 ... bench: 21447 ns/iter (+/- 45)
test be_i32 ... bench: 23832 ns/iter (+/- 63)
test be_i64 ... bench: 26887 ns/iter (+/- 267)
test le_i8 ... bench: 21442 ns/iter (+/- 56)
test le_i16 ... bench: 21448 ns/iter (+/- 36)
test le_i32 ... bench: 23825 ns/iter (+/- 153)
test le_i64 ... bench: 26271 ns/iter (+/- 138)
````
After:
````
test be_i8 ... bench: 21438 ns/iter (+/- 10)
test be_i16 ... bench: 21441 ns/iter (+/- 15)
test be_i32 ... bench: 19057 ns/iter (+/- 6)
test be_i64 ... bench: 21439 ns/iter (+/- 34)
test le_i8 ... bench: 21438 ns/iter (+/- 19)
test le_i16 ... bench: 21439 ns/iter (+/- 8)
test le_i32 ... bench: 21439 ns/iter (+/- 19)
test le_i64 ... bench: 21438 ns/iter (+/- 22)
````
LLVM fails to properly optimize the shifts used to convert the source
value to the right endianess. The resulting assembly copies the value
to the stack one byte at a time even when there's no conversion required
(e.g. u64_to_le_bytes on a little endian machine).
Instead of doing the conversion ourselves using shifts, we can use the
existing intrinsics to perform the endianess conversion and then
transmute the value to get a fixed vector of its bytes.
Before:
test be_i8 ... bench: 21442 ns/iter (+/- 70)
test be_i16 ... bench: 21447 ns/iter (+/- 45)
test be_i32 ... bench: 23832 ns/iter (+/- 63)
test be_i64 ... bench: 26887 ns/iter (+/- 267)
test le_i8 ... bench: 21442 ns/iter (+/- 56)
test le_i16 ... bench: 21448 ns/iter (+/- 36)
test le_i32 ... bench: 23825 ns/iter (+/- 153)
test le_i64 ... bench: 26271 ns/iter (+/- 138)
After:
test be_i8 ... bench: 21438 ns/iter (+/- 10)
test be_i16 ... bench: 21441 ns/iter (+/- 15)
test be_i32 ... bench: 19057 ns/iter (+/- 6)
test be_i64 ... bench: 21439 ns/iter (+/- 34)
test le_i8 ... bench: 21438 ns/iter (+/- 19)
test le_i16 ... bench: 21439 ns/iter (+/- 8)
test le_i32 ... bench: 21439 ns/iter (+/- 19)
test le_i64 ... bench: 21438 ns/iter (+/- 22)
bors [Sat, 1 Feb 2014 08:46:23 +0000 (00:46 -0800)]
auto merge of #11963 : alexcrichton/rust/fix-rustpkg, r=brson
Right now the bots are all injecting a libstd version, so all the rustpkg tests
are passing. All rustpkg compilations will fail unless the version number is
explicitly given because rustpkg attempts to exactly guess the target file name.
Switch back to using a pattern match in order to unbreak tests.
Huon Wilson [Fri, 31 Jan 2014 14:46:30 +0000 (01:46 +1100)]
Remove the obsolete handler for `impl A;`.
This is has been obsolete for quite a while now (including a release),
so removing the special handling seems fine. (The error message is quite
good still anyway.)
bors [Sat, 1 Feb 2014 02:21:41 +0000 (18:21 -0800)]
auto merge of #11885 : bnoordhuis/rust/issue11694, r=alexcrichton
EINVAL means that the requested stack size is either not a multiple
of the system page size or that it's smaller than PTHREAD_STACK_MIN.
Figure out what the case is, fix it up and retry. If it still fails,
give up, like before.
Suggestions for future improvements:
* don't fail!() but instead signal a condition, or
* silently ignore the error and use a default sized stack.
Fixes #11694.
The first two commits put the framework in place, the third one contains the meat.
Alex Crichton [Fri, 31 Jan 2014 23:56:37 +0000 (15:56 -0800)]
Fix rustpkg tests with --disable-inject-std-version
Right now the bots are all injecting a libstd version, so all the rustpkg tests
are passing. All rustpkg compilations will fail unless the version number is
explicitly given because rustpkg attempts to exactly guess the target file name.
Switch back to using a pattern match in order to unbreak tests.
bors [Fri, 31 Jan 2014 23:11:32 +0000 (15:11 -0800)]
auto merge of #11810 : Armavica/rust/issue-11645, r=alexcrichton
The doc-generating tool comments out the lines that match `/$# /` (note the space), which is not what is wanted here. And it lets live the lines matching `/$#[^ ]/`. But we still want to see a space. So I replaced the normal space by a non breakable one, which fools the parser into displaying the line.
bors [Fri, 31 Jan 2014 21:06:39 +0000 (13:06 -0800)]
auto merge of #11832 : jfager/rust/r5900, r=alexcrichton
I tried a couple of different ways to squash this, and still don't think this is ideal, but I wanted to get it out for feedback.
Closes #5900
Closes #9942
There are a few scenarios where the compiler tries to evaluate CastExprs without the corresponding types being available yet in the type context: https://github.com/mozilla/rust/issues/10618, https://github.com/mozilla/rust/issues/5900, https://github.com/mozilla/rust/issues/9942
This PR takes the approach of having eval_const_expr_partial's CastExpr arm fall back to a limited ast_ty_to_ty call that only checks for (a subset of) valid const types, when the direct type lookup fails. It's kind of hacky, so I understand if you don't want to take this as is. I'd need a little mentoring to get this into better shape, as figuring out the proper fix has been a little daunting. I'm also happy if someone else wants to pick this up and run with it.
This closes 5900 and 9942, but only moves the goalposts a little on 10618, which now falls over in a later phase of the compiler.
Ben Noordhuis [Wed, 29 Jan 2014 17:19:23 +0000 (18:19 +0100)]
Use __pthread_get_minstack() when available.
glibc >= 2.15 has a __pthread_get_minstack() function that returns
PTHREAD_STACK_MIN plus however many bytes are needed for thread-local
storage. Use it when it's available because just PTHREAD_STACK_MIN is
not enough in applications that have big thread-local storage
requirements.
projects / rust.git / log