declared with the same name in the same scope.
This breaks several common patterns. First are unused imports:
use foo::bar;
use baz::bar;
Change this code to the following:
use baz::bar;
Second, this patch breaks globs that import names that are shadowed by
subsequent imports. For example:
use foo::*; // including `bar`
use baz::bar;
Change this code to remove the glob:
use foo::{boo, quux};
use baz::bar;
Or qualify all uses of `bar`:
use foo::{boo, quux};
use baz;
... baz::bar ...
Finally, this patch breaks code that, at top level, explicitly imports
`std` and doesn't disable the prelude.
extern crate std;
Because the prelude imports `std` implicitly, there is no need to
explicitly import it; just remove such directives.
The old behavior can be opted into via the `import_shadowing` feature
gate. Use of this feature gate is discouraged.
This implements RFC #116.
Closes#16464.
[breaking-change]
These are already marked as `noalias` due to the immutability guarantee
(see 4c2d4cd3dea344e81e4df24382ac3f23e2f86f40), but more information can
be bubbled up to the caller via `readonly`.
When a struct implements Drop, its fields should still drop in
declaration order (just as they do when the struct does not implement
Drop).
Fixes#16492.
When a struct implements Drop, its fields should still drop in
declaration order (just as they do when the struct does not implement
Drop).
Fixes#16492.
The discriminant for Option values is either 0 or 1, so we can just
truncate the value to an i1, which ends up as a no-op for Options
containing pointers.
These are already marked as `noalias` due to the immutability guarantee
(see 4c2d4cd3dea344e81e4df24382ac3f23e2f86f40), but more information can
be bubbled up to the caller via `readonly`.
The discriminant for Option values is either 0 or 1, so we can just
truncate the value to an i1, which ends up as a no-op for Options
containing pointers.
These `where` clauses are accepted everywhere generics are currently
accepted and desugar during type collection to the type parameter bounds
we have today.
A new keyword, `where`, has been added. Therefore, this is a breaking
change. Change uses of `where` to other identifiers.
[breaking-change]
r? @nikomatsakis (or whoever)
These `where` clauses are accepted everywhere generics are currently
accepted and desugar during type collection to the type parameter bounds
we have today.
A new keyword, `where`, has been added. Therefore, this is a breaking
change. Change uses of `where` to other identifiers.
[breaking-change]
methods.
This paves the way to associated items by introducing an extra level of
abstraction ("impl-or-trait item") between traits/implementations and
methods. This new abstraction is encoded in the metadata and used
throughout the compiler where appropriate.
There are no functional changes; this is purely a refactoring.
This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.
This breaks code that looked like:
let mut f;
{
let x = &5i;
f = |&mut:| *x + 10;
}
Change this code to avoid having a reference escape. For example:
{
let x = &5i;
let mut f; // <-- move here to avoid dangling reference
f = |&mut:| *x + 10;
}
I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.
Closes#14449.
[breaking-change]
r? @pnkfelix
This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.
This breaks code that looked like:
let mut f;
{
let x = &5i;
f = |&mut:| *x + 10;
}
Change this code to avoid having a reference escape. For example:
{
let x = &5i;
let mut f; // <-- move here to avoid dangling reference
f = |&mut:| *x + 10;
}
I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.
Closes#14449.
[breaking-change]
by-reference upvars.
This partially implements RFC 38. A snapshot will be needed to turn this
on, because stage0 cannot yet parse the keyword.
Part of #12381.
This fixes borrow checking for closures. Code like this will break:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
let p = &this.x;
&mut this.x;
};
r()
}
Change this code to not take multiple mutable references to the same value. For
example:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
&mut this.x;
};
r()
}
Closes#16361.
[breaking-change]
r? @nikomatsakis
`for` loop heads.
This breaks code like:
let x = Some(box 1i);
for &a in x.iter() {
}
Change this code to obey the borrow checking rules. For example:
let x = Some(box 1i);
for &ref a in x.iter() {
}
Closes#16205.
[breaking-change]
r? @nikomatsakis
`for` loop heads.
This breaks code like:
let x = Some(box 1i);
for &a in x.iter() {
}
Change this code to obey the borrow checking rules. For example:
let x = Some(box 1i);
for &ref a in x.iter() {
}
Closes#16205.
[breaking-change]
This fixes borrow checking for closures. Code like this will break:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
let p = &this.x;
&mut this.x;
};
r()
}
Change this code to not take multiple mutable references to the same value. For
example:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
&mut this.x;
};
r()
}
Closes#16361.
[breaking-change]
For historical reasons, "Win32" has been used in Rust codebase to mean "Windows OS in general".
This is confusing, especially now, that Rust supports Win64 builds.
[breaking-change]
The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
This generalises the behaviour with struct fields (which recieve no
dead_code warning if they have a leading _), and other similar lints, to
all items, e.g. `fn _foo() {} fn main() {}` has no warnings.
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
