bors [Mon, 15 Aug 2016 01:36:33 +0000 (18:36 -0700)]
Auto merge of #35427 - cardoe:arm-musl-targets, r=alexcrichton
add GNU make files for arm-unknown-linux-musleabi
For Yocto (Embedded Linux meta distro) Rust is provided via the [meta-rust layer](https://github.com/meta-rust/meta-rust). In this project there have been patches to add `arm-unknown-linux-musleabi`. Rust recently acquired that support via #35060 but only for rustbuild. meta-rust is currently only able to build Rust support with the existing GNU Makefiles. This adds `arm-unknown-linux-musleabi` support to Rust for the GNU Makefiles until meta-rust is able to sort out why using rustbuild does not work for it.
bors [Sun, 14 Aug 2016 19:28:48 +0000 (12:28 -0700)]
Auto merge of #35409 - eddyb:mir-storage-stmts, r=nikomatsakis
[MIR] Add Storage{Live,Dead} statements to emit llvm.lifetime.{start,end}.
Storage live ranges are tracked for all MIR variables and temporaries with a drop scope.
`StorageLive` is lowered to `llvm.lifetime.start` and `StorageDead` to `llvm.lifetime.end`.
There are some improvements possible here, such as:
* pack multiple storage liveness statements by using the index of first local + `u64` bitset
* enforce that locals are not directly accessed outside their storage live range
* shrink storage live ranges for never-borrowed locals to initialization -> last use
* emit storage liveness statements for *all* temporaries
* however, the remaining ones are *always* SSA immediates, so they'd be noop in MIR trans
* could have a flag on the temporary that its storage is irrelevant (a la C's old `register`)
* would also deny borrows if necessary
* this seems like an overcompliation and with packing & optimizations it may be pointless
Even in the current state, it helps stage2 `rustc` compile `boiler` without overflowing (see #35408).
A later addition fixes #26764 and closes #27372 by emitting `.section` directives for dylib metadata to avoid them being allocated into memory or read as `.note`. For this PR, those bugs were tripping valgrind.
Rollup merge of #35620 - cvubrugier:master, r=Manishearth
book: fix the hidden find() functions in error-handling.md
The hidden find() functions always returns None. Consequently, one of the
examples using find() prints "No file extension found" instead of
"File extension: rs" which is the expected output.
This patch fixes the issue by implementing find() with std::str::find().
Rollup merge of #35611 - jonathandturner:ptr-helper, r=nikomatsakis
Improve &-ptr printing
This PR replaces printing `&-ptr` with a more readable description. To do so it uses a few heuristics.
If the name of the type is unknown, too long (longer than just saying "reference"), or too complex (a type with explicit lifetime annotations), it will instead opt to print either "reference" or "mutable reference", depending on the mutability of the type.
Before:
```
error[E0308]: mismatched types
--> src/test/compile-fail/issue-7061.rs:14:46
|
14 | fn foo(&'a mut self) -> Box<BarStruct> { self }
| ^^^^ expected box, found &-ptr
|
= note: expected type `Box<BarStruct>`
= note: found type `&'a mut BarStruct`
error: aborting due to previous error
```
After:
```
error[E0308]: mismatched types
--> src/test/compile-fail/issue-7061.rs:14:46
|
14 | fn foo(&'a mut self) -> Box<BarStruct> { self }
| ^^^^ expected box, found mutable reference
|
= note: expected type `Box<BarStruct>`
= note: found type `&'a mut BarStruct`
Rollup merge of #35574 - badboy:emscripten-test-fixes, r=brson
Emscripten test fixes
This picks up parts of #31623 to disable certain tests that emscripten can't run, as threads/processes are not supported.
I re-applied @tomaka's changes manually, I can rebase those commits with his credentials if he wants.
It also disables jemalloc for emscripten (at least in Rustbuild, I have to check if there is another setting for the same thing in the old makefile approach).
This should not impact anything for normal builds.
Question: How can I only underline the function name ? I have observed the debug output and the struct of item, but I can't find the `Span` for function name. Should I modify the struct I get to save function name's position or there is another way to get it ? (I can only find `Span`s for function attributes, inputs, outputs, blocks)
Rollup merge of #35539 - cgswords:ts_concat, r=nrc
Implemented a smarter TokenStream concatenation system
The new algorithm performs 'aggressive compacting' during concatenation as follows:
- If the nodes' combined total total length is less than 32, we copy both of
them into a new vector and build a new leaf node.
- If one node is an internal node and the other is a 'small' leaf (length<32),
we recur down the internal node on the appropriate side.
- Otherwise, we construct a new internal node that points to them as left and
right.
This should produce notably better behavior than the current concatenation implementation.
Rollup merge of #35444 - alexcrichton:optimize-catch-unwind, r=brson
std: Optimize panic::catch_unwind slightly
The previous implementation of this function was overly conservative with
liberal usage of `Option` and `.unwrap()` which in theory never triggers. This
commit essentially removes the `Option`s in favor of unsafe implementations,
improving the code generation of the fast path for LLVM to see through what's
happening more clearly.
Rollup merge of #35392 - malbarbo:cell-from, r=brson
Implement From for Cell, RefCell and UnsafeCell
Considering that `From` is implemented for `Box`, `Rc` and `Arc`, it seems [reasonable](https://internals.rust-lang.org/t/implementing-from-t-for-other-std-types/3744) to implement it for `Cell`, `RefCell` and `UnsafeCell`.
bors [Sun, 14 Aug 2016 06:37:11 +0000 (23:37 -0700)]
Auto merge of #35453 - jseyfried:hygienize_metavariables, r=nrc
macros: Make metavariables hygienic
This PR makes metavariables hygienic. For example, consider:
```rust
macro_rules! foo {
($x:tt) => { // Suppose that this token tree argument is always a metavariable.
macro_rules! bar { ($x:expr, $y:expr) => { ($x, $y) } }
}
}
fn main() {
foo!($z); // This currently compiles.
foo!($y); // This is an error today but compiles after this PR.
}
```
Today, the `macro_rules! bar { ... }` definition is only valid when the metavariable passed to `foo` is not `$y` (since it unhygienically conflicts with the `$y` in the definition of `bar`) or `$x` (c.f. #35450).
After this PR, the definition of `bar` is always valid (and `bar!(a, b)` always expands to `(a, b)` as expected).
This can break code that was allowed in #34925 (landed two weeks ago). For example,
```rust
macro_rules! outer {
($t:tt) => {
macro_rules! inner { ($i:item) => { $t } }
}
}
outer!($i); // This `$i` should not interact with the `$i` in the definition of `inner!`.
inner!(fn main() {}); // After this PR, this is an error ("unknown macro variable `i`").
```
Due to the severe limitations on nested `macro_rules!` before #34925, this is not a breaking change for stable/beta.
bors [Sat, 13 Aug 2016 16:52:49 +0000 (09:52 -0700)]
Auto merge of #35414 - jupp0r:feature/test-threads-flag, r=alexcrichton
Add --test-threads option to test binaries
This change allows parallelism of test runs to be specified by a
command line flag names --test-threads in addition to the existing
environment variable RUST_TEST_THREADS. Fixes #25636.
book: fix the hidden find() functions in error-handling.md
The hidden find() functions always returns None. Consequently, one of the
examples using find() prints "No file extension found" instead of
"File extension: rs" which is the expected output.
This patch fixes the issue by implementing find() with std::str::find().
bors [Fri, 12 Aug 2016 08:26:12 +0000 (01:26 -0700)]
Auto merge of #35091 - eddyb:impl-trait, r=nikomatsakis
Implement `impl Trait` in return type position by anonymization.
This is the first step towards implementing `impl Trait` (cc #34511).
`impl Trait` types are only allowed in function and inherent method return types, and capture all named lifetime and type parameters, being invariant over them.
No lifetimes that are not explicitly named lifetime parameters are allowed to escape from the function body.
The exposed traits are only those listed explicitly, i.e. `Foo` and `Clone` in `impl Foo + Clone`, with the exception of "auto traits" (like `Send` or `Sync`) which "leak" the actual contents.
// is represented as:
type A</*invariant over*/ T> where A<T>: Iterator<Item=B<T>>;
type B</*invariant over*/ T> where B<T>: FnOnce() -> T;
fn foo<T>(xs: Vec<T>) -> A<T> {
xs.into_iter().map(|x| || x): $0 where $0: Iterator<Item=$1>, $1: FnOnce() -> T
}
```
`$0` and `$1` are resolved (to `iter::Map<vec::Iter<T>, closure>` and the closure, respectively) and assigned to `A` and `B`, after checking the body of `foo`. `A` and `B` are *never* resolved for user-facing type equality (typeck), but always for the low-level representation and specialization (trans).
The "auto traits" exception is implemented by collecting bounds like `impl Trait: Send` that have failed for the obscure `impl Trait` type (i.e. `A` or `B` above), pretending they succeeded within the function and trying them again after type-checking the whole crate, by replacing `impl Trait` with the real type.
While passing around values which have explicit lifetime parameters (of the function with `-> impl Trait`) in their type *should* work, regionck appears to assign inference variables in *way* too many cases, and never properly resolving them to either explicit lifetime parameters, or `'static`.
We might not be able to handle lifetime parameters in `impl Trait` without changes to lifetime inference, but type parameters can have arbitrary lifetimes in them from the caller, so most type-generic usecases (or not generic at all) should not run into this problem.
Alex Crichton [Sat, 9 Jul 2016 02:45:37 +0000 (19:45 -0700)]
std: Optimize panic::catch_unwind slightly
The previous implementation of this function was overly conservative with
liberal usage of `Option` and `.unwrap()` which in theory never triggers. This
commit essentially removes the `Option`s in favor of unsafe implementations,
improving the code generation of the fast path for LLVM to see through what's
happening more clearly.
Everyone in the issue discussion seemed to be in favor, @huonw also spoke about this [here](https://www.reddit.com/r/rust/comments/3xldr9/surfaces_and_signatures_component_privacy_versus/cy615wq), but the issue haven't got any movement.
I think it's reasonable to do this before turning `private_in_public` warnings into errors.
Jonathan Turner [Thu, 11 Aug 2016 13:34:02 +0000 (06:34 -0700)]
Rollup merge of #35576 - circuitfox:E0072-update-error-format, r=jonathandturner
E0072 update error format
Part of #35233
Fixes #35506
r? @jonathandturner
The bonus for this issue currently seems to be impossible to do reliably, as the compiler seems to lack span information for item names alone, like `Foo` in `struct Foo { ... }`. It would be possible to hack something together by computing span offsets, but that seems like a solution that would be begging for trouble.
A proper solution to this would, of course, be to add span information to the right place (seems to be `rustc::hir::Item::name` but I may be wrong).
Jonathan Turner [Thu, 11 Aug 2016 13:34:01 +0000 (06:34 -0700)]
Rollup merge of #35562 - birkenfeld:as-mut-doc, r=steveklabnik
Remove redundant `&mut ref mut` in doc for Result::as_mut()
While a good example of how `&mut ref mut` is a no-op, I don't think we should show that here :)
See https://users.rust-lang.org/t/mnemonic-for-reading-qualifiers/6853