| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
Closes #17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
|
|
|
|
This reverts commit 2288f332301b9e22db2890df256322650a7f3445.
|
|
|
|
0.12.0 release
|
|
|
|
|
|
|
|
r? @aturon
|
|
|
|
|
|
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
|
|
[Previously](https://github.com/rust-lang/rust/commit/e5da6a71a6a0b46dd3630fc8326e6d5906a1fde6),
the `Any` trait was split into a private portion and an (empty) public
portion, in order to hide the implementation strategy used for
downcasting. However, the [new
rules](https://github.com/rust-lang/rust/commit/e9ad12c0cae5c43ada6641c7dc840a0fbe5010a2)
for privacy forbid `AnyPrivate` from actually being private.
This patch thus reverts the introduction of `AnyPrivate`.
Although this is unlikely to break any real code, it removes a public
trait and is therefore a:
[breaking-change]
|
|
r=alexcrichton
Add example to doc for `slice::ImmutableSlice::binary_search`.
Fix #17817.
|
|
Fix #17817.
|
|
I'm not sure how to add an automated test for this.
|
|
|
|
The examples for fetch_or, fetch_and and fetch_xor for
std::sync::atomic::AtomicInt used AtomicUint instead of AtomicInt.
|
|
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
|
|
|
|
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
|
|
This reverts commit df2f1fa7680a86ba228f004e7de731e91a1df1fe.
|
|
This reverts commit 95cfc35607ccf5f02f02de56a35a9ef50fa23a82.
|
|
This reverts commit 6e0611a48707a1f5d90aee32a02b2b15957ef25b.
|
|
This also requires a fix for Vec's MoveItems. This resolves issue #16941
|
|
|
|
|
|
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
Deprecates slicing methods from ImmutableSlice/MutableSlice in favour of slicing syntax or the methods in Slice/SliceMut.
Closes #17273.
|
|
|
|
This bound is already implicit through the AnyPrivate trait,
but since it is not explicit, you still have to write Box<Any + 'static>,
even though Any can only be 'static.
Introducing the 'static bound here makes this bound explicit, making
Box<Any> legal.
|
|
This bound is already implicit through the AnyPrivate trait,
but since it is not explicit, you still have to write Box<Any + 'static>,
even though Any can only be 'static.
Introducing the 'static bound here makes this bound explicit, making
Box<Any> legal.
|
|
This breaks code that looks like:
match foo {
1..3 => { ... }
}
Instead, write:
match foo {
1...3 => { ... }
}
Closes #17295.
[breaking-change]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #17502
|
|
This is the inverse of `Result::ok` and helps to bridge `Option` and
`Result` based APIs.
|
|
Fixes #17470.
|
|
The syntax sugar is `[mut from..to]` not `[from..to]`
|
|
These are the inverses of `Result::ok` and help to bridge `Option` and
`Result` based APIs.
|
|
The for loop would *always* exaust the iterator previously, which seems
like behavior that was not intended. It's still kind of a weird
function.
|
