Use an absolute path in test_process_output_fail_to_start

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.
Add a limited prim type lookup for safer const expr evaluation
Remove unused imports.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Prefix _ to unused variables.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Append ; to #[allow(dead_code)].

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
remove a layer of indirection from most intrinsics
Add test case for issue #11681
Fix inconsistency in tutorial.md

Text refers to "the type shown earlier", when the type in
question was not in fact shown earlier.  I assume this is
an artifact of an earlier revision.
Make size_of, align_of, and element_offset functions return u64 instead of uint in trans::machine (per #5172)
auto merge of #11759 : nathanielherman/rust/master, r=alexcrichton

For #5172
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
Fix the size of the _Unwind_Exception struct

On OSX 32-bit, the private fields are 5 words long, not 2. I found this
segfaulting before this change, and after this change it no longer segfaulted.
auto merge of #11947 : alexcrichton/rust/osx-unwind, r=brson

On OSX 32-bit, the private fields are 5 words long, not 2. I found this
segfaulting before this change, and after this change it no longer segfaulted.
auto merge of #11918 : omasanori/rust/reduce-warnings, r=alexcrichton

Moving forward to green waterfall.
auto merge of #11929 : FlaPer87/rust/issue-11681, r=huonw

closes #11681
auto merge of #11933 : kini/rust/patch-1, r=alexcrichton

Text refers to "the type shown earlier", when the type in
question was not in fact shown earlier.  I assume this is
an artifact of an earlier revision.
auto merge of #11917 : thestinger/rust/intrinsic, r=alexcrichton
Disable fp elim on mac64

I believe that this is leading to lots of failures on the bots.

cc #11954
auto merge of #11955 : alexcrichton/rust/fix-unwinding-on-mac-64, r=cmr

I believe that this is leading to lots of failures on the bots.

cc #11954
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.