| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
constructors
Closes #19999
[breaking-change]
Use [_; n] instead.
|
|
|
|
position
Closes #20093.
|
|
r? @huonw
|
|
Since runtime is removed, rust has no tasks anymore and everything is moving
from being task-* to thread-*. Let’s rename TaskRng as well!
This is a breaking change. If a breaking change for consistency is not desired, feel free to close.
|
|
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.
|
|
I've totally mangled the history with these rebases; sorry, future programmer!
|
|
(on platforms with 64-bit pointers.)
The StmtMac variant is rather large and also fairly rare, so let's
optimise the common case.
|
|
Since runtime is removed, rust has no tasks anymore and everything is moving
from being task-* to thread-*. Let’s rename TaskRng as well!
* Rename TaskRng to ThreadRng
* Rename task_rng to thread_rng
[breaking-change]
|
|
|
|
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 breaks code that looks like this:
let x = foo as bar << 13;
Change such code to look like this:
let x = (foo as bar) << 13;
Closes #17362.
[breaking-change]
|
|
|
|
RFC 248? I think you meant RFC 438.
There ain’t an RFC 248, while 438 looks to be what is being referred to:
https://github.com/rust-lang/rfcs/blob/master/text/0438-precedence-of-plus.md
--------------
Chis Morgan has a pretty important documentation fix in #19385 and he hasn't responded in a while to that pull request so I rebased it for him
Closes #19385
|
|
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.
All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.
To migrate all crates, add the following to your `Cargo.toml`:
[dependencies]
rustc-serialize = "0.1.1"
And then add the following to your crate root:
extern crate "rustc-serialize" as rustc_serialize;
Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.
[breaking-change]
|
|
There ain’t an RFC 248, while 438 looks to be what is being referred to:
https://github.com/rust-lang/rfcs/blob/master/text/0438-precedence-of-plus.md
|
|
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.
All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.
To migrate all crates, add the following to your `Cargo.toml`:
[dependencies]
rustc-serialize = "0.1.1"
And then add the following to your crate root:
extern crate "rustc-serialize" as rustc_serialize;
Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.
[breaking-change]
|
|
|
|
This does NOT break any existing programs because the `[_, ..n]` syntax is also supported.
Part of #19999
r? @nikomatsakis
|
|
Fixes #19991.
|
|
|
|
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`.
|
|
|
|
|
|
results.
|
|
integrating into rustdoc etc.
|
|
|
|
language. Recommend `move||` instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 9b443289cf32cbcff16768614340f0c844675340.
|
|
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]
|
|
Now that we have an overloaded comparison (`==`) operator, and that `Vec`/`String` deref to `[T]`/`str` on method calls, many `as_slice()`/`as_mut_slice()`/`to_string()` calls have become redundant. This patch removes them. These were the most common patterns:
- `assert_eq(test_output.as_slice(), "ground truth")` -> `assert_eq(test_output, "ground truth")`
- `assert_eq(test_output, "ground truth".to_string())` -> `assert_eq(test_output, "ground truth")`
- `vec.as_mut_slice().sort()` -> `vec.sort()`
- `vec.as_slice().slice(from, to)` -> `vec.slice(from_to)`
---
Note that e.g. `a_string.push_str(b_string.as_slice())` has been left untouched in this PR, since we first need to settle down whether we want to favor the `&*b_string` or the `b_string[]` notation.
This is rebased on top of #19167
cc @alexcrichton @aturon
|
|
|
|
|
|
|
|
As an example of what this changes, the following code:
```rust
let x: [int ..4];
```
Currently spits out ‘expected `]`, found `..`’. However, a comma would also be valid there, as would a number of other tokens. This change adjusts the parser to produce more accurate errors, so that that example now produces ‘expected one of `(`, `+`, `,`, `::`, or `]`, found `..`’.
(Thanks to cramer on IRC for pointing out this problem with diagnostics.)
|
