- 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
On AArch64, libc::c_char is u8. There are some places in the code where i8 is assumed, which causes compilation errors.
(AArch64 is not officially supported yet, but this change does not hurt any other targets and makes the code future-proof.)
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.
Closes#19473.
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.
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.
Fixes#19452.
in most cases, just the error message changed, but in some cases we
are reporting new errors that OUGHT to have been reported before but
we're overlooked (mostly involving the `'static` bound on `Send`).
This pull request tries to fix#19340, which states two ICE cases related to enum struct variants.
It is my first attempt to fix the compiler. I found this solution by trial and error, so the method used to fix the issue looks very hacky. Please review it, and direct me to find a better solution.
I'm also to add test cases. Where should I put them? Maybe `src/test/run-pass/issue-19340.rs`?
The current behavior leads to adjustments like `&&*` being applied
instead of just `&` (when the unmodified receiver is a `&T` or an `&mut
T`). This causes both safety errors and unexpected behavior. The safety
errors result from regionck not being prepared for auto-ref-ref-like
adjustments; this is worth fixing on its own, but I think the best way
to do it is to modify regionck to use expr-use-visitor (and fix
expr-use-visitor as well, which I don't think properly invokes `borrow`
for each level of auto-ref), and for now it's simpler to just not
produce the adjustment in question. (I have a separate patch porting
regionck to use exprusevisitor for a different bug, so that is coming.)
Previously, the DeBruijn index for the self type was not being
adjusted to account for the fn binder. This mean that when late-bound
regions were instantiated, you sometimes wind up with two distinct
lifetimes.
Fixes#19537.
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.
Fixes#19452.
When a type error occurs, check_method_argument_types() tries to provide
arguments filled with ty::mk_err(). However, if a function takes the
parameters as a tuple, the arguments should be converted to a tuple
before being passed to check_argument_types().
Fixes#19521.
One of the causes of #19501 was that the metadata on OSX was getting corrupted.
For any one particular invocation of the compiler the metadata file inside of an
rlib archive would have extra bytes appended to the end of it. These extra bytes
end up confusing rbml and have it run off the end of the array (resulting in the
out of bounds detected).
This commit prepends the length of metadata to the start of the metadata to
ensure that we always slice the precise amount that we want, and it also
un-ignores the test from #19502.
Closes#19501
This means that `Fn(&A) -> (&B, &C)` is equivalent to `for<'a> Fn(&'a A)
-> (&'a B, &'a C)` similar to the lifetime elision of lower-case `fn` in
types and declarations.
Closes#18992.
Reported as a part of rust-lang/rust#19120
The logic of rust-lang/rust@74fb798a20 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.
