bors [Wed, 17 Dec 2014 02:42:57 +0000 (02:42 +0000)]
auto merge of #19761 : nick29581/rust/coerce-double, r=nikomatsakis
Part of #18469
[breaking-change]
A receiver will only ever get a single auto-reference. Previously arrays and strings would get two, e.g., [T] would be auto-ref'ed to &&[T]. This is usually apparent when a trait is implemented for `&[T]` and has a method takes self by reference. The usual solution is to implement the trait for `[T]` (the DST form).
Nick Cameron [Fri, 12 Dec 2014 00:23:21 +0000 (13:23 +1300)]
Remove the double auto-ref on arrays/strings as receivers
Part of #18469
[breaking-change]
A receiver will only ever get a single auto-reference. Previously arrays and strings would get two, e.g., [T] would be auto-ref'ed to &&[T]. This is usually apparent when a trait is implemented for `&[T]` and has a method takes self by reference. The usual solution is to implement the trait for `[T]` (the DST form).
bors [Mon, 15 Dec 2014 22:11:44 +0000 (22:11 +0000)]
auto merge of #19448 : japaric/rust/binops-by-value, r=nikomatsakis
- The following operator traits now take their arguments by value: `Add`, `Sub`, `Mul`, `Div`, `Rem`, `BitAnd`, `BitOr`, `BitXor`, `Shl`, `Shr`. This breaks all existing implementations of these traits.
- The binary operation `a OP b` now "desugars" to `OpTrait::op_method(a, b)` and consumes both arguments.
- `String` and `Vec` addition have been changed to reuse the LHS owned value, and to avoid internal cloning. Only the following asymmetric operations are available: `String + &str` and `Vec<T> + &[T]`, which are now a short-hand for the "append" operation.
[breaking-change]
---
This passes `make check` locally. I haven't touch the unary operators in this PR, but converting them to by value should be very similar to this PR. I can work on them after this gets the thumbs up.
@nikomatsakis r? the compiler changes
@aturon r? the library changes. I think the only controversial bit is the semantic change of the `Vec`/`String` `Add` implementation.
cc #19148
Niko Matsakis [Fri, 12 Dec 2014 16:09:24 +0000 (11:09 -0500)]
Emit warning when lifetime names are shadowed.
This is not technically a [breaking-change], but it will be soon, so
you should update your code. Typically, shadowing is accidental, and
the shadowing lifetime can simply be removed. This frequently occurs
in constructor patterns:
Brian Anderson [Sun, 14 Dec 2014 02:24:42 +0000 (18:24 -0800)]
rollup merge of #19812: frewsxcv/expansion-include-enum
In preparation for [removing the `std::cmp::Ordering` reexport](https://github.com/rust-lang/rust/issues/19253), this needs to be done to prevent errors like:
```
note: in expansion of #[deriving]
note: expansion site
error: unresolved name `std::cmp::Equal`
#[deriving(Clone, PartialEq, PartialOrd, Eq, Ord, Show)]
^~~
```
Brian Anderson [Sun, 14 Dec 2014 02:23:00 +0000 (18:23 -0800)]
rollup merge of #19763: csouth3/remove-featuregates
This is a revival of #19517 (per request of @alexcrichton) now that the new snapshots have landed. We can now remove the last feature gates for if_let, while_let, and tuple_indexing scattered throughout the test sources since these features have been added to Rust.
bors [Mon, 15 Dec 2014 08:32:45 +0000 (08:32 +0000)]
auto merge of #19750 : murarth/rust/rusti-support, r=brson
Makes a couple changes that support the implementation of a REPL:
* Implementation of wrapper code for LLVM ExecutionEngine API
* Fixing a change I made earlier to reset compiler state in `phase_1_[...]`
instead of `compile_input` as the latter is not used in a REPL
bors [Sun, 14 Dec 2014 19:07:29 +0000 (19:07 +0000)]
auto merge of #19703 : nikomatsakis/rust/unsafe-trait, r=acrichto
This PR allows declaring traits and impls as `unsafe`. An `unsafe` trait requires an `unsafe` impl. An `unsafe` impl does not permit unsafe code within its interior (unless that code is contained within an unsafe block or unsafe fn, as normal). The commits are standalone.
bors [Sun, 14 Dec 2014 11:37:27 +0000 (11:37 +0000)]
auto merge of #19338 : nikomatsakis/rust/unboxed-closure-purge-the-proc, r=acrichto
They are replaced with unboxed closures.
cc @pcwalton @aturon
This is a [breaking-change]. Mostly, uses of `proc()` simply need to be converted to `move||` (unboxed closures), but in some cases the adaptations required are more complex (particularly for library authors). A detailed write-up can be found here: http://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/
The commits are ordered to emphasize the more important changes, but are not truly standalone.
bors [Sun, 14 Dec 2014 09:22:24 +0000 (09:22 +0000)]
auto merge of #19690 : barosl/rust/struct-variant-as-a-function-ice, r=alexcrichton
Unlike a tuple variant constructor which can be called as a function, a struct variant constructor is not a function, so cannot be called.
If the user tries to assign the constructor to a variable, an ICE occurs, because there is no way to use it later. So we should stop the constructor from being used like that.
A similar mechanism already exists for a normal struct, as it prohibits a struct from being resolved. This commit does the same for a struct variant.
This commit also includes some changes to the existing tests.
Niko Matsakis [Thu, 20 Nov 2014 17:12:38 +0000 (12:12 -0500)]
Purge the hack that allows `FnOnce` to be used with a by-value self method. Besides being yucky, it will cause problems if we try to make all traits implement themselves, which would make a lot of things in life easier. Also, it was inextricably linked to `Box`, which was not the intention. We can work around its absence, so better to reimplement it later in a more thorough fashion.