| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
As per https://github.com/rust-lang/rust/issues/20405. To be more precise, the changes just the processing of enums when the name is "RUST$ENCODED$ENUM$..." so it correctly parses when there is more than one number encoding the location of the field it's looking for to determine state of the enum
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/libflate/lib.rs
src/libstd/lib.rs
src/libstd/macros.rs
src/libsyntax/feature_gate.rs
src/libsyntax/parse/parser.rs
src/libsyntax/show_span.rs
src/test/auxiliary/macro_crate_test.rs
src/test/compile-fail/lint-stability.rs
src/test/run-pass/intrinsics-math.rs
src/test/run-pass/tcp-connect-timeouts.rs
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/librustc/middle/traits/mod.rs
src/libstd/io/mod.rs
src/test/run-pass/builtin-superkinds-self-type.rs
|
|
Conflicts:
src/test/compile-fail/borrowck-loan-rcvr-overloaded-op.rs
|
|
|
|
|
|
|
|
printers enabled.
|
|
|
|
|
|
This reverts commit b0481147184a8ee70f066423dc077ffa0bd821b5.
|
|
This reverts commit 87c5927b79b8eec8763659da8a3cf4561a4ceabd.
|
|
This does NOT break any existing programs because the `[_, ..n]` syntax is also supported.
Part of #19999
r? @nikomatsakis
|
|
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]
|
|
|
|
Fixes #19575.
|
|
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]
|
|
|
|
|
|
|
|
Also see issue #18791.
|
|
|
|
|
|
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
|
|
|
|
On some Windows versions of GDB this is more stable than setting breakpoints via function names.
|
|
Conflicts:
src/libcollections/slice.rs
src/libcore/failure.rs
src/libsyntax/parse/token.rs
src/test/debuginfo/basic-types-mut-globals.rs
src/test/debuginfo/simple-struct.rs
src/test/debuginfo/trait-pointers.rs
|
|
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
|
|
|
|
available
|
|
|
|
The old name is misleading as we haven't had segmented stacks in quite some
time. But we still recognize it, with a deprecation warning.
|
|
LLDB doesn't allow for reading 'artifical' fields (fields that are generated by the compiler). So do not mark, slice fields, enum discriminants, and GcBox value fields as artificial.
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
|
|
|
|
Conflicts:
src/libcollections/lib.rs
src/libcore/lib.rs
src/librustdoc/lib.rs
src/librustrt/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/test/run-pass/issue-8898.rs
|
