The names expected and actual are not used anymore in the output. It also
removes the confusion that the argument order is the opposite of junit.
Bug #7330 is relevant.
per rfc 459
cc https://github.com/rust-lang/rust/issues/19390
One question is: should we start by warning, and only switch to hard error later? I think we discussed something like this in the meeting.
r? @alexcrichton
Was testing rustup on a very minimal Debian installation and got errors during the install process (error occurred in `install.sh` of the Rust nightly.)
Noticed that Rustup was downloading the i686 nightly instead of x86-64. Installing `file` fixed the problem, and this patch adds the probe to ensure file is installed before attempting to use it.
There may still be an issue with the i686 installation, I did not investigate further.
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).
This commit performs a second pass stabilization of the `std::default` module.
The module was already marked `#[stable]`, and the inheritance of `#[stable]`
was removed since this attribute was applied. This commit adds the `#[stable]`
attribute to the trait definition and one method name, along with all
implementations found in the standard distribution.
This commit takes a second pass through the `std::mem` module for stabilization.
The only remaining non-stable items in this module were `forget`, `transmute`,
`copy_lifetime`, and `copy_lifetime_mut`.
The `forget` and `transmute` intrinsics themselves were marked `#[stable]` to
propgate into the `core::mem` module so they would be marked stable.
The `copy_lifetime` functions were left `unstable`, but `Sized?` annotations
were added to the parameters to allow more general use with DSTs.
The `size_of_val`, `min_align_of_val`, and `align_of_val` functions would like
to grow `Sized?` bounds, but this is a backwards compatible change that
currently ICEs the compiler, so this change was not made at this time.
Finally, the module itself was declared `#![stable]` in this pass.
This commit collapses the various prelude traits for slices into just one trait:
* SlicePrelude/SliceAllocPrelude => SliceExt
* CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt
* OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt
* PartialEqSlicePrelude => PartialEqSliceExt
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 `HashSet` 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:
[breaking-change].
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 `HashMap` 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:
[breaking-change].
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:
[breaking-change].
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:
[breaking-change].
- 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
visualization of region inference constraint graph.
Optionally uses environment variables `RUST_REGION_GRAPH=<path_template>`
and `RUST_REGION_GRAPH_NODE=<node-id>` to select which file to output
to and which AST node to print.
Note that in some cases of method AST's, the identification of AST
node is based on the id for the *body* of the method; this is largely
due to having the body node-id already available at the relevant point
in the control-flow of rustc in its current incarnation. Ideally we
would handle identifying AST's by name in addition to node-id,
e.g. the same way that the pretty-printer supports path suffixes as
well as node-ids for identifying subtrees to print.
Relax some of the bounds on the decoder methods back to FnMut to help accomodate
some more flavorful variants of decoders which may need to run the closure more
than once when it, for example, attempts to find the first successful enum to
decode.
This a breaking change due to the bounds for the trait switching, and clients
will need to update from `FnOnce` to `FnMut` as well as likely making the local
function binding mutable in order to call the function.
[breaking-change]
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:
```rust
// Old:
impl<'a> SomeStruct<'a> { fn new<'a>(..) -> SomeStruct<'a> { ... } }
// Should be:
impl<'a> SomeStruct<'a> { fn new(..) -> SomeStruct<'a> { ... } }
```
Otherwise, you should rename the inner lifetime to something
else. Note though that lifetime elision frequently applies:
```rust
// Old
impl<'a> SomeStruct<'a> {
fn get<'a>(x: &'a self) -> &'a T { &self.field }
}
// Should be:
impl<'a> SomeStruct<'a> {
fn get(x: &self) -> &T { &self.field }
}
``
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)]
^~~
```
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.)
