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.
Ben Noordhuis [Tue, 28 Jan 2014 12:21:31 +0000 (13:21 +0100)]
Retry on EINVAL from pthread_attr_setstacksize()
Enforce that the stack size is > RED_ZONE + PTHREAD_STACK_MIN. If the
call to pthread_attr_setstacksize() subsequently fails with EINVAL, it
means that the platform requires the stack size to be a multiple of the
page size. In that case, round up to the nearest page and retry.
bors [Fri, 31 Jan 2014 02:11:30 +0000 (18:11 -0800)]
auto merge of #11784 : eminence/rust/fix_run_tests, r=alexcrichton
This test is designed to ensure that running a non-existent executable
results in a correct error message (FileNotFound in this case of this
test). However, if you try to run an executable that doesn't exist, and
that requires searching through the $PATH, and one of the $PATH components
is not readable, then a PermissionDenied error will be returned, instead
of FileNotFound.
Using an absolute path skips the $PATH search logic in exec, thus by-passing the logic in exec that would have returned a PermissionDenied
In the specific case of my machine, /usr/bin/games was part of $PATH, but my user account wasn't in the games group (thus being unable to read /usr/bin/games)
See the man pages for execv and execve for more details.
I've tested this on Linux and OSX, and I am fairly certain that there will be no problems on Windows
bors [Thu, 30 Jan 2014 07:46:26 +0000 (23:46 -0800)]
auto merge of #11853 : alexcrichton/rust/up-llvm, r=brson
This upgrade brings commit by @eddyb to help optimizations of virtual calls in
a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a
commit by @c-a to *greatly* improve the runtime of the optimization passes
(https://github.com/rust-lang/llvm/pull/3).
Alex Crichton [Mon, 27 Jan 2014 20:45:48 +0000 (12:45 -0800)]
Upgrade LLVM
This upgrade brings commit by @eddyb to help optimizations of virtual calls in
a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a
commit by @c-a to *greatly* improve the runtime of the optimization passes
(https://github.com/rust-lang/llvm/pull/3).
bors [Thu, 30 Jan 2014 06:21:29 +0000 (22:21 -0800)]
auto merge of #11839 : typelist/rust/issue3008, r=huonw
It was possible to trigger a stack overflow in rustc because the routine used to verify enum representability,
type_structurally_contains, would recurse on inner types until hitting the original type. The overflow condition was when a different structurally recursive type (enum or struct) was contained in the type being checked.
I suspect my solution isn't as efficient as it could be. I pondered adding a cache of previously-seen types to avoid duplicating work (if enums A and B both contain type C, my code goes through C twice), but I didn't want to do anything that may not be necessary.
I'm a new contributor, so please pay particular attention to any unidiomatic code, misuse of terminology, bad naming of tests, or similar horribleness :)
Updated to verify struct representability as well.
bors [Thu, 30 Jan 2014 04:06:36 +0000 (20:06 -0800)]
auto merge of #11672 : bjz/rust/remove-times, r=brson
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal (which I liked) was then lost after `do` was disabled for closures. It's time to let this one go.
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal was then lost after `do` was disabled for closures. It's time to let this one go.
Daniel Micay [Tue, 28 Jan 2014 19:59:28 +0000 (14:59 -0500)]
enable fp-elim when debug info is disabled
This can almost be fully disabled, as it no longer breaks retrieving a
backtrace on OS X as verified by @alexcrichton. However, it still
breaks retrieving the values of parameters. This should be fixable in
the future via a proper location list...
bors [Wed, 29 Jan 2014 17:46:34 +0000 (09:46 -0800)]
auto merge of #11754 : alexcrichton/rust/unused-result, r=brson
The general consensus is that we want to move away from conditions for I/O, and I propose a two-step plan for doing so:
1. Warn about unused `Result` types. When all of I/O returns `Result`, it will require you inspect the return value for an error *only if* you have a result you want to look at. By default, for things like `write` returning `Result<(), Error>`, these will all go silently ignored. This lint will prevent blind ignorance of these return values, letting you know that there's something you should do about them.
With these two tools combined, I feel that we get almost all the benefits of conditions. The first step (the lint) is a sanity check that you're not ignoring return values at callsites. The second step is to provide a convenience method of returning early out of a sequence of computations. After thinking about this for awhile, I don't think that we need the so-called "do-notation" in the compiler itself because I think it's just *too* specialized. Additionally, the `try!` macro is super lightweight, easy to understand, and works almost everywhere. As soon as you want to do something more fancy, my answer is "use match".
Basically, with these two tools in action, I would be comfortable removing conditions. What do others think about this strategy?
----
This PR specifically implements the `unused_result` lint. I actually added two lints, `unused_result` and `unused_must_use`, and the first commit has the rationale for why `unused_result` is turned off by default.
bors [Wed, 29 Jan 2014 14:26:38 +0000 (06:26 -0800)]
auto merge of #11867 : dmanescu/rust/8784-arena-glob, r=huonw
In line with the dissolution of libextra - #8784 - this moves arena and glob into
their own respective modules. Updates .gitignore with the entries
doc/{arena,glob} in accordance.