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.)
Fixes#9580.
Introduce marker types for indicating variance and for opting out
of builtin bounds.
Fixes#10834.
Fixes#11385.
cc #5922.
r? @pnkfelix (since you reviewed the variance inference in the first place)
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.
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.
Closes#11852
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.
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#5900Closes#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.
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.
Fixes#6233.
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.
Fixes#11694.
Represents the minimum size of a thread's stack. As such, it's both
platform and architecture-specific.
I put it under posix01 even though it predates POSIX.1-2001 by some
years. I believe it was first formalized in SUSv2. I doubt anyone
cares, though.
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
