| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #17904. All the cases that I believe we should support are detailed in the test case, let me know if there is there is any more desired behavior. cc @japaric.
r? @nikomatsakis or whoever is appropriate.
|
|
|
|
|
|
|
|
This implements RFC 179 by making the pattern `&<pat>` require matching
against a variable of type `&T`, and introducing the pattern `&mut
<pat>` which only works with variables of type `&mut T`.
The pattern `&mut x` currently parses as `&(mut x)` i.e. a pattern match
through a `&T` or a `&mut T` that binds the variable `x` to have type
`T` and to be mutable. This should be rewritten as follows, for example,
for &mut x in slice.iter() {
becomes
for &x in slice.iter() {
let mut x = x;
Due to this, this is a
[breaking-change]
Closes #20496.
|
|
This commit introduces the syntax for negative implmenetations of traits
as shown below:
`impl !Trait for Type {}`
cc #13231
Part of RFC #3
|
|
|
|
|
|
Conflicts:
src/test/compile-fail/borrowck-loan-rcvr-overloaded-op.rs
|
|
|
|
[breaking-change]
`mod` is still accepted, but gives a deprecated warning
|
|
Part of #19607.
r? @nikomatsakis
|
|
[breaking-change]
The `mut` in slices is now redundant. Mutability is 'inferred' from position. This means that if mutability is only obvious from the type, you will need to use explicit calls to the slicing methods.
|
|
Note that this doesn't add the surface syntax.
|
|
(on platforms with 64-bit pointers.)
The StmtMac variant is rather large and also fairly rare, so let's
optimise the common case.
|
|
|
|
Includes a bit of refactoring to store `?` unbounds as bounds with a modifier, rather than in their own world, in the AST at least.
|
|
|
|
|
|
|
|
|
|
This does NOT break any existing programs because the `[_, ..n]` syntax is also supported.
Part of #19999
r? @nikomatsakis
|
|
|
|
Implement support in the parser for generalized where clauses,
as well as the conversion of ast::WherePredicates to
ty::Predicate in `collect.rs`.
|
|
This does NOT break any existing programs because the `[_, ..n]` syntax is also supported.
|
|
|
|
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes #18635.
[breaking-change]
|
|
This is to allow us to migrate away from UnUniq in a followup commit,
and thus unify the code paths related to all forms of `box`.
|
|
Fixes #19358.
|
|
This is to allow us to migrate away from UnUniq in a followup commit,
and thus unify the code paths related to all forms of `box`.
|
|
|
|
results.
|
|
integrating into rustdoc etc.
|
|
|
|
language. Recommend `move||` instead.
|
|
|
|
|
|
|
|
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
|
|
|
|
|
|
No semantic changes, no enabling `if let` where it wasn't already enabled.
|
|
Otherwise `--pretty expanded` diverges.
|
|
No semantic changes, no enabling `if let` where it wasn't already enabled.
|
|
This makes it correct (e.g. avoiding null pointers) and safe.
|
|
bounds.
|
|
|
|
appropriately.
|
|
This makes it correct (e.g. avoiding null pointers) and safe.
|
|
Closes https://github.com/rust-lang/rust/issues/19077
I would appreciate any guidance on how to write a test for this. I saw some examples in `test/pretty`, but there are different ways to test... With or without `.pp` files, with a `pp-exact` comment, etc.
|
