Jonathan Turner [Thu, 29 Sep 2016 03:21:52 +0000 (20:21 -0700)]
Rollup merge of #36794 - japaric:target-panic, r=alexcrichton
add a panic-strategy field to the target specification
Now a target can define its panic strategy in its specification. If a
user doesn't specify a panic strategy via the command line, i.e. '-C
panic', then the compiler will use the panic strategy defined by the
target specification.
Custom targets can pick their panic strategy via the "panic-strategy"
field of their target specification JSON file. If omitted in the
specification, the strategy defaults to "unwind".
closes #36647
---
I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this?
Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate.
Jonathan Turner [Thu, 29 Sep 2016 03:21:52 +0000 (20:21 -0700)]
Rollup merge of #36789 - jseyfried:non_inline_mod_in_block, r=nikomatsakis
Allow more non-inline modules in blocks
Currently, non-inline modules without a `#[path]` attribute are not allowed in blocks.
This PR allows non-inline modules that have an ancestor module with a `#[path]` attribute, provided there is not a nearer ancestor block.
For example,
```rust
fn main() {
#[path = "..."] mod foo {
mod bar; //< allowed by this PR
fn f() {
mod bar; //< still an error
}
}
}
```
Jonathan Turner [Thu, 29 Sep 2016 03:21:51 +0000 (20:21 -0700)]
Rollup merge of #36741 - matklad:no-flacky-test, r=alexcrichton
Remove CString drop test.
The test relies on the undefined behavior, and so may fail in some
circumstances. This can be worked around by stubbing a memory allocator
in the test, but it is a bit of work, and LLVM could still theoretically
eliminate the write of the zero byte in release mode (which is
intended).
So let's just remove the test and mark the function as inline. It
shouldn't be optimized away when inlined into the debug build of user's
code.
Jonathan Turner [Thu, 29 Sep 2016 03:21:51 +0000 (20:21 -0700)]
Rollup merge of #36704 - Mark-Simulacrum:cleanup-cabi, r=Aatch
Move ty_align and ty_size out of most C ABI code
s390x's C ABI ty_align and ty_size are not moved because the
implementation of ty_align varies in an atypical pattern: it calls
ty_size for the llvm::Vector type kind. ty_size then cannot be moved
since it indirectly calls ty_align through align.
Jonathan Turner [Wed, 28 Sep 2016 17:33:58 +0000 (10:33 -0700)]
Rollup merge of #36796 - TimNN:mips64-data-layout, r=japaric
update mips64* data-layout
I tried to compile some (`#![no_core]`) code for the `mips64` targets on the latest nightly and got ICE's about mismatched data layouts. I updated the data layouts to match the listed llvm defaults.
Jonathan Turner [Wed, 28 Sep 2016 17:33:57 +0000 (10:33 -0700)]
Rollup merge of #36784 - jonathandturner:env_var, r=alexcrichton
Remove requirement to use 10.7 (fixes macOS)
Fixes https://github.com/rust-lang/rust/issues/36650 by removing the requirement to use 10.7. @alexcrichton pointed out that the buildbots won't be affected, since they set the requirement with an environment variable.
This should now allow rustbuild to build Rust on macOS (nee OS X)
Jonathan Turner [Wed, 28 Sep 2016 17:33:57 +0000 (10:33 -0700)]
Rollup merge of #36782 - alexcrichton:rustc-macro-expand-order, r=nrc
rustc: Tweak expansion order of custom derive
This commit alters the expansion order of custom macros-1.1 style `#[derive]`
modes. Instead of left-to-right the expansion now happens in three categories,
each of which is internally left-to-right:
* Old-style custom derive (`#[derive_Foo]`) is expanded
* New-style custom derive (macros 1.1) is expanded
* Built in derive modes are expanded
This gives built in derive modes maximal knowledge about the struct that's being
expanded and also avoids pesky issues like exposing `#[structural_match]` or
`#[rustc_copy_clone_marker]`.
Auto merge of #36604 - japaric:libtest-skip, r=alexcrichton
libtest: add a --skip flag to the test runner
This flag takes a FILTER argument and instructs the test runner to skip
the tests whose names contain the word FILTER. --skip can be used
several times.
---
My motivation for submitting this is that while using [smoke] to run `std` unit tests for cross
targets I found that a few of the tests always fail due to limitations in QEMU (it can't handle too
many threads) and I'd like to skip these problematic tests from the command line to be able to run
the rest of the unit tests.
[smoke]: https://github.com/japaric/smoke
I know there is another mechanism to skip tests: `#[ignore]` but this doesn't work in my use case
because I can't (easily) modify the source of the standard libraries to `#[ignore]` some tests. And
even if I could, the change would involve conditionally ignoring some tests for some targets but
that's not a perfect solution because those tests should pass if executed on real hardware so they
should not be `#[ignored]` in that scenario.
Auto merge of #36776 - alexcrichton:rustc-macro-dep-files, r=nrc
rustc: Use a special filename for macros 1.1
This "special filename" is surrounded by `<>` to ensure that
`FileMap::is_real_file` returns `false`. This way the "files" parsed here aren't
emitted as dep info `.d` files and don't confuse Cargo about non-existent files.
add a panic-strategy field to the target specification
Now a target can define its panic strategy in its specification. If a
user doesn't specify a panic strategy via the command line, i.e. '-C
panic', then the compiler will use the panic strategy defined by the
target specification.
Custom targets can pick their panic strategy via the "panic-strategy"
field of their target specification JSON file. If omitted in the
specification, the strategy defaults to "unwind".
Alex Crichton [Tue, 27 Sep 2016 18:51:56 +0000 (11:51 -0700)]
rustc: Tweak expansion order of custom derive
This commit alters the expansion order of custom macros-1.1 style `#[derive]`
modes. Instead of left-to-right the expansion now happens in three categories,
each of which is internally left-to-right:
* Old-style custom derive (`#[derive_Foo]`) is expanded
* New-style custom derive (macros 1.1) is expanded
* Built in derive modes are expanded
This gives built in derive modes maximal knowledge about the struct that's being
expanded and also avoids pesky issues like exposing `#[structural_match]` or
`#[rustc_copy_clone_marker]`.
Alex Crichton [Tue, 27 Sep 2016 18:19:03 +0000 (11:19 -0700)]
rustc: Use a special filename for macros 1.1
This "special filename" is surrounded by `<>` to ensure that
`FileMap::is_real_file` returns `false`. This way the "files" parsed here aren't
emitted as dep info `.d` files and don't confuse Cargo about non-existent files.
Auto merge of #36761 - jonathandturner:E0425_E0446_E0449, r=nrc
Update E0425, E0446, E0449
This addresses https://github.com/rust-lang/rust/issues/35343, https://github.com/rust-lang/rust/issues/35923, and https://github.com/rust-lang/rust/issues/35924. Part of https://github.com/rust-lang/rust/issues/35233
Specifically, this adds labels to these error messages following the suggestions in the attached bugs.
Auto merge of #36678 - TimNN:fix-dist, r=alexcrichton
emit feature help in cheat mode (fix nightlies)
This should fix the `distcheck` failure in the latest nightly.
cc #36539
It's probably not ideal to check the environment that often and the code ist duplicated from `librustc/session/config.rs` but this was the easiest fix I could think of.
A cleaner solution would probably be to move the `unstable_features` from `Options` to `ParseSess` and change the `diag` parameter of `emit_feature_err` to take `ParseSess` instead of a `Handler`.
Jonathan Turner [Tue, 27 Sep 2016 00:29:49 +0000 (17:29 -0700)]
Rollup merge of #36727 - kallisti5:master, r=Aatch
Haiku: Initial work at OS support
These changes should be non-invasive to non-Haiku platforms. These patches were hand reworked from Neil's original Rust 1.9.0 patches. I've done some style cleanup and design updates along the way.
There are a few small additional patches to libc, rust-installer and compiler-rt that will be submitted once this one is accepted.
Haiku can be compiled on Linux, and a full gcc cross-compiler with a Haiku target is available, which means bootstrapping should be fairly easy. The patches here have already successfully bootstrapped under our haiku x86_gcc2 architecture. http://rust-on-haiku.com/wiki/PortingRust
I'll be focusing on our more modern gcc5 x86 and x86 architectures for now.
As for support, we're not seeking official support for now. We understand Haiku isn't a top-tier OS choice, however having these patches upstream greatly reduces the amount of patchwork we have to do. Mesa has Haiku code upstream, and we submit patches to keep it going. Mesa doesn't test on Haiku and we're ok with that :-)
Jonathan Turner [Tue, 27 Sep 2016 00:29:48 +0000 (17:29 -0700)]
Rollup merge of #36676 - bluss:rustdoc-where-css, r=steveklabnik
rustdoc css: Put `where` in trait listings on a new line
This is about the gray area at the top of a trait's documentation page,
that lists all methods and their signatures. A big trait page like
Iterator is very crowded without this tweak.
This passes three arguments to rustc: `-C` `link-args="-Tlayout.ld` and
`-nostartfiles"` to `rustc`. That's not what we meant. But this does
what we want:
Makes it so the signature of the intrinsic in the user's code is
"found," while the signature that rustc knows about is "expected."
Before this patch, the code
```
extern "platform-intrinsic" {
fn x86_mm_movemask_ps() -> i32;
}
```
would give the error
```
error[E0444]: platform-specific intrinsic has invalid number of arguments: found 1, expected 0
--> test.rs:4:5
|
4 | fn x86_mm_movemask_ps() -> i32;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The test relies on the undefined behavior, and so may fail in some
circumstances. This can be worked around by stubbing a memory allocator
in the test, but it is a bit of work, and LLVM could still theoretically
eliminate the write of the zero byte in release mode (which is
intended).
So let's just remove the test and mark the function as inline. It
shouldn't be optimized away when inlined into the debug build of user's
code.