Chase Southwood [Sat, 13 Dec 2014 05:14:57 +0000 (23:14 -0600)]
Use wrapper structs for `BTreeSet`'s iterators.
Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.
This commit changes the iterators of `BTreeSet` to use
proper new types, rather than type aliases. However, since it is
fair-game to treat a type-alias as the aliased type, this is a:
Chase Southwood [Fri, 12 Dec 2014 06:04:47 +0000 (00:04 -0600)]
Use wrapper structs for `BTreeMap`'s iterators.
Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.
This commit changes the keys and values iterators of `BTreeMap` to use
proper new types, rather than type aliases. However, since it is
fair-game to treat a type-alias as the aliased type, this is a:
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
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.
bors [Sat, 13 Dec 2014 22:57:21 +0000 (22:57 +0000)]
auto merge of #19467 : japaric/rust/uc, r=alexcrichton
This PR moves almost all our current uses of closures, both in public API and internal uses, to the new "unboxed" closures system.
In most cases, downstream code that *only uses* closures will continue to work as it is. The reason is that the `|| {}` syntax can be inferred either as a boxed or an "unboxed" closure according to the context. For example the following code will continue to work:
And will get silently upgraded to an "unboxed" closure.
In some other cases, it may be necessary to "annotate" which `Fn*` trait the closure implements:
```
// Change this
|x| { /* body */}
// to either of these
|: x| { /* body */} // closure implements the FnOnce trait
|&mut : x| { /* body */} // FnMut
|&: x| { /* body */} // Fn
```
This mainly occurs when the closure is assigned to a variable first, and then passed to a function/method.
``` rust
let closure = |: x| x.transform_with(upvar);
some.option.map(closure)
```
(It's very likely that in the future, an improved inference engine will make this annotation unnecessary)
Other cases that require annotation are closures that implement some trait via a blanket `impl`, for example:
``` rust
string.trim_left_chars(|c: char| c.is_whitespace())
//~^ ERROR: the trait `Fn<(char,), bool>` is not implemented for the type `|char| -> bool`
string.trim_left_chars(|&: c: char| c.is_whitespace()) // OK
```
Finally, all implementations of traits that contain boxed closures in the arguments of their methods are now broken. And will need to be updated to use unboxed closures. These are the main affected traits:
I've chosen the bounds to make the functions/structs as "generic as possible", i.e. to let them allow the maximum amount of input.
- An `F: FnOnce` bound accepts the three kinds of closures: `|:|`, `|&mut:|` and `|&:|`.
- An `F: FnMut` bound only accepts "non-consuming" closures: `|&mut:|` and `|&:|`.
- An `F: Fn` bound only accept the "immutable environment" closures: `|&:|`.
This means that whenever possible the `FnOnce` bound has been used, if the `FnOnce` bound couldn't be used, then the `FnMut` was used. The `Fn` bound was never used in the whole repository.
The `FnMut` bound was the most used, because it resembles the semantics of the current boxed closures: the closure can modify its environment, and the closure may be called several times.
The `FnOnce` bound allows new semantics: you can move out the upvars when the closure is called. This can be effectively paired with the `move || {}` syntax to transfer ownership from the environment to the closure caller.
In the case of trait methods, is hard to select the "right" bound since we can't control how the trait may be implemented by downstream users. In these cases, I have selected the bound based on how we use these traits in the repository. For this reason the selected bounds may not be ideal, and may require tweaking before stabilization.