This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system do a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes#16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
Next steps are to disable the existing out-of-tree behavior for stability attributes, and convert the remaining system to be feature-based per the RFC. During the first beta cycle we will set these lints to 'forbid'.
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
To avoid using the feauture, change uses of `box <expr>` to
`Box::new(<expr>)` alternative, as noted by the feature gate message.
(Note that box patterns have no analogous trivial replacement, at
least not in general; you need to revise the code to do a partial
match, deref, and then the rest of the match.)
[breaking-change]
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes#16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
This commit performs a pass over the implementations of the new `String` trait
in the formatting module. Some implementations were removed as a conservative
move pending an upcoming convention about `String` implementations, and some
were added in order to retain consistency across the libraries. Specifically:
* All "smart pointers" implement `String` now, adding missing implementations
for `Arc` and `Rc`.
* The `Vec<T>` and `[T]` types no longer implement `String`.
* The `*const T` and `*mut T` type no longer implement `String`.
* The `()` type no longer implements `String`.
* The `Path` type's `Show` implementation does not surround itself with `Path
{}` (a minor tweak).
All implementations of `String` in this PR were also marked `#[stable]` to
indicate that the types will continue to implement the `String` trait regardless
of what it looks like.
This commit performs a pass over the `std::macros` module, applying stability
attributes where necessary. In particular, this audits macros for patterns such
as:
* Standard use of forward-to-format-args via `$($arg:tt)*` (or `+`)
* Prevent macro-defined identifiers from leaking into expression arguments as
hygiene is not perfectly implemented.
* Wherever possible, `$crate` is used now.
Specifically, the following actions were taken:
* The `std::macros` module itself is no longer public.
* The `panic!` macro is stable
* The `assert!` macro is stable
* The `assert_eq!` macro is stable
* The `debug_assert!` macro is stable
* The `debug_assert_eq!` macro is stable
* The `unreachable!` macro is stable after removing the extra forms to bring the
definition in line with the `unimplemented!` macro.
* The `try!` macro is stable
* The `vec!` macro is stable
[breaking-change]
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
This PR introduces `isize` and `usize` modules to `core` and `std`, and
deprecates the existing `int` and `uint` modules. The rustdoc primitive
type links now point to these new modules.
Due to deprecation this is a:
[breaking-change]
Believe or not, `CreateProcess()` is racy if several threads create
child processes: [0], [1], [2].
This caused some tests show crash dialogs during
`make check-stage#-rpass`.
More explanation:
On Windows, `SetErrorMode()` controls display of error dialogs: it
accepts new error mode and returns old error mode.
The error mode is process-global and automatically inherited to child
process when created.
MSYS2 bash shell internally sets it to not show error dialogs, therefore
`make check-stage#-rpass` should not show them either.
However, [1] says that `CreateProcess()` internally invokes
`SetErrorMode()` twice: at first it sets mode `0x8001` and saves
original mode, and at second it restores original mode.
So if two threads simultaneously call `CreateProcess()`, the first
thread sets error mode to `0x8001` then the second thread recognizes
that current error mode is `0x8001`. Therefore, The second thread will
create process with wrong error mode.
This really occurs inside `compiletest`: it creates several processes on
each thread, so some `run-pass` tests are invoked with wrong error mode
therefore show crash dialog.
This commit adds `StaticMutex` for `CreateProcess()` call. This seems
to fix the "dialog annoyance" issue.
[0]: http://support.microsoft.com/kb/315939
[1]: https://code.google.com/p/nativeclient/issues/detail?id=2968
[2]: https://ghc.haskell.org/trac/ghc/ticket/2650
This commit takes a first pass at stabilizing `std::thread`:
* It removes the `detach` method in favor of two constructors -- `spawn`
for detached threads, `scoped` for "scoped" (i.e., must-join)
threads. This addresses some of the surprise/frustrating debug
sessions with the previous API, in which `spawn` produced a guard that
on destruction joined the thread (unless `detach` was called).
The reason to have the division in part is that `Send` will soon not
imply `'static`, which means that `scoped` thread creation can take a
closure over *shared stack data* of the parent thread. On the other
hand, this means that the parent must not pop the relevant stack
frames while the child thread is running. The `JoinGuard` is used to
prevent this from happening by joining on drop (if you have not
already explicitly `join`ed.) The APIs around `scoped` are
future-proofed for the `Send` changes by taking an additional lifetime
parameter. With the current definition of `Send`, this is forced to be
`'static`, but when `Send` changes these APIs will gain their full
flexibility immediately.
Threads that are `spawn`ed, on the other hand, are detached from the
start and do not yield an RAII guard.
The hope is that, by making `scoped` an explicit opt-in with a very
suggestive name, it will be drastically less likely to be caught by a
surprising deadlock due to an implicit join at the end of a scope.
* The module itself is marked stable.
* Existing methods other than `spawn` and `scoped` are marked stable.
The migration path is:
```rust
Thread::spawn(f).detached()
```
becomes
```rust
Thread::spawn(f)
```
while
```rust
let res = Thread::spawn(f);
res.join()
```
becomes
```rust
let res = Thread::scoped(f);
res.join()
```
[breaking-change]
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
This is a manual merge of #20627 and #20634 to avoid conflicts in rollup and also avoid one roundtrip. I've leave copyright to original author. If this one is moved to rollup original PR could be closed. cc @mneumann
@alexcrichton r?
Both FreeBSD and DragonFly define pthread_key_t as int, while Linux
defines it as uint. As pthread_key_t is used as an opaque type and
storage size of both int and uint are the same, this is rather a
cosmetic change.
iOS uses ulong (as OS X) so difference is critical on 64bit platforms.
This commit is a first past stabilization of `std::error`:
* The module is stable.
* The `FromError` trait and impls are stable
* The `Error` trait itself is left unstable, pending current APIs and
possible revisions during the alpha cycle.
This calculates the width and height using the bounding box of the window in the buffer. Bounding box coordinates are inclusive so I have to add 1 to both dimensions.
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
Both FreeBSD and DragonFly define pthread_key_t as int, while Linux
defines it as uint. As pthread_key_t is used as an opaque type and
storage size of both int and uint are the same, this is rather a
cosmetic change.
iOS uses ulong (as OS X) so difference is critical on 64bit platforms.
Believe or not, `CreateProcess()` is racy if several threads create
child processes: [0], [1], [2].
This caused some tests show crash dialogs during
`make check-stage#-rpass`.
More explanation:
On Windows, `SetErrorMode()` controls display of error dialogs: it
accepts new error mode and returns old error mode.
The error mode is process-global and automatically inherited to child
process when created.
MSYS2 bash shell internally sets it to not show error dialogs, therefore
`make check-stage#-rpass` should not show them either.
However, [1] says that `CreateProcess()` internally invokes
`SetErrorMode()` twice: at first it sets mode `0x8001` and saves
original mode, and at second it restores original mode.
So if two threads simultaneously call `CreateProcess()`, the first
thread sets error mode to `0x8001` then the second thread recognizes
that current error mode is `0x8001`. Therefore, The second thread will
create process with wrong error mode.
This really occurs inside `compiletest`: it creates several processes on
each thread, so some `run-pass` tests are invoked with wrong error mode
therefore show crash dialog.
This commit adds `StaticMutex` for `CreateProcess()` call. This seems
to fix the "dialog annoyance" issue.
[0]: http://support.microsoft.com/kb/315939
[1]: https://code.google.com/p/nativeclient/issues/detail?id=2968
[2]: https://ghc.haskell.org/trac/ghc/ticket/2650
This commit is a first past stabilization of `std::error`:
* The module is stable.
* The `FromError` trait and impls are stable
* The `Error` trait itself is left unstable, pending current APIs and
possible revisions during the alpha cycle.
This commit takes a first pass at stabilizing `std::thread`:
* It removes the `detach` method in favor of two constructors -- `spawn`
for detached threads, `scoped` for "scoped" (i.e., must-join)
threads. This addresses some of the surprise/frustrating debug
sessions with the previous API, in which `spawn` produced a guard that
on destruction joined the thread (unless `detach` was called).
The reason to have the division in part is that `Send` will soon not
imply `'static`, which means that `scoped` thread creation can take a
closure over *shared stack data* of the parent thread. On the other
hand, this means that the parent must not pop the relevant stack
frames while the child thread is running. The `JoinGuard` is used to
prevent this from happening by joining on drop (if you have not
already explicitly `join`ed.) The APIs around `scoped` are
future-proofed for the `Send` changes by taking an additional lifetime
parameter. With the current definition of `Send`, this is forced to be
`'static`, but when `Send` changes these APIs will gain their full
flexibility immediately.
Threads that are `spawn`ed, on the other hand, are detached from the
start and do not yield an RAII guard.
The hope is that, by making `scoped` an explicit opt-in with a very
suggestive name, it will be drastically less likely to be caught by a
surprising deadlock due to an implicit join at the end of a scope.
* The module itself is marked stable.
* Existing methods other than `spawn` and `scoped` are marked stable.
The migration path is:
```rust
Thread::spawn(f).detached()
```
becomes
```rust
Thread::spawn(f)
```
while
```rust
let res = Thread::spawn(f);
res.join()
```
becomes
```rust
let res = Thread::scoped(f);
res.join()
```
[breaking-change]
`FloatMath` no longer exists and all functionality from both traits is
available under `Float`. Change from
use std::num::{Float, FloatMath};
to
use std::num::Float;
[breaking-change]
This commit is an implementation of [RFC 494][rfc] which removes the entire
`std::c_vec` module and redesigns the `std::c_str` module as `std::ffi`.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0494-c_str-and-c_vec-stability.md
The interface of the new `CString` is outlined in the linked RFC, the primary
changes being:
* The `ToCStr` trait is gone, meaning the `with_c_str` and `to_c_str` methods
are now gone. These two methods are replaced with a `CString::from_slice`
method.
* The `CString` type is now just a wrapper around `Vec<u8>` with a static
guarantee that there is a trailing nul byte with no internal nul bytes. This
means that `CString` now implements `Deref<Target = [c_char]>`, which is where
it gains most of its methods from. A few helper methods are added to acquire a
slice of `u8` instead of `c_char`, as well as including a slice with the
trailing nul byte if necessary.
* All usage of non-owned `CString` values is now done via two functions inside
of `std::ffi`, called `c_str_to_bytes` and `c_str_to_bytes_with_nul`. These
functions are now the one method used to convert a `*const c_char` to a Rust
slice of `u8`.
Many more details, including newly deprecated methods, can be found linked in
the RFC. This is a:
[breaking-change]
Closes#20444
The previous scheme made it possible for another user/attacker to cause the
temporary directory creation scheme to panic. All you needed to know was the pid
of the process you wanted to target ('other_pid') and the suffix it was using
(let's pretend it's 'sfx') and then code such as this would, in essence, DOS it:
for i in range(0u, 1001) {
let tp = &Path::new(format!("/tmp/rs-{}-{}-sfx", other_pid, i));
match fs::mkdir(tp, io::USER_RWX) { _ => () }
}
Since the scheme only 1000 times to create a temporary directory before dying,
the next time the attacked process called TempDir::new("sfx") after that would
typically cause a panic. Of course, you don't necessarily need an attacker to
cause such a DOS: creating 1000 temporary directories without closing any of the
previous would be enough to DOS yourself.
This patch broadly follows the OpenBSD implementation of mkstemp. It uses the
operating system's random number generator to produce random directory names
that are impractical to guess (and, just in case someone manages to do that, it
retries creating the directory for a long time before giving up; OpenBSD
retries INT_MAX times, although 1<<31 seems enough to thwart even the most
patient attacker).
As a small additional change while the file name is changing, this patch also
makes the argument that TempDir::new takes a prefix rather than a suffix.
This is because 1) it more closely matches what mkstemp and friends do 2)
if you're going to have a deterministic part of a filename, you really want it at
the beginning so that shell completion is useful.
* Implement (derive) `Clone` for `ChaChaRng`, `Isaac*Rng`, `StdRng` and `ThreadRng`;
* Derive `XorShiftRng` `Clone` implementation instead of implementing it explicitly.
`OsRng` is the only Rng which does not implement `Clone` or `Copy` after this patch because of its dependence on `Reader`.
r? @huonw I guess?
macro_rules! is like an item that defines a macro. Other items don't have a
trailing semicolon, or use a paren-delimited body.
If there's an argument for matching the invocation syntax, e.g. parentheses for
an expr macro, then I think that applies more strongly to the *inner*
delimiters on the LHS, wrapping the individual argument patterns.
The earlier collections stabilization did not cover the modules
themselves. This commit marks as stable those modules whose types have
been stabilized.
Many of libstd's macros are now re-exported from libcore and libcollections.
Their libstd definitions have moved to a macros_stage0 module and can disappear
after the next snapshot.
Where the two crates had already diverged, I took the libstd versions as
they're generally newer and better-tested. See e.g. d3c831b, which was a fix to
libstd's assert_eq!() that didn't make it into libcore's.
Fixes#16806.
This commit is an implementation of [RFC 494][rfc] which removes the entire
`std::c_vec` module and redesigns the `std::c_str` module as `std::ffi`.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0494-c_str-and-c_vec-stability.md
The interface of the new `CString` is outlined in the linked RFC, the primary
changes being:
* The `ToCStr` trait is gone, meaning the `with_c_str` and `to_c_str` methods
are now gone. These two methods are replaced with a `CString::from_slice`
method.
* The `CString` type is now just a wrapper around `Vec<u8>` with a static
guarantee that there is a trailing nul byte with no internal nul bytes. This
means that `CString` now implements `Deref<Target = [c_char]>`, which is where
it gains most of its methods from. A few helper methods are added to acquire a
slice of `u8` instead of `c_char`, as well as including a slice with the
trailing nul byte if necessary.
* All usage of non-owned `CString` values is now done via two functions inside
of `std::ffi`, called `c_str_to_bytes` and `c_str_to_bytes_with_nul`. These
functions are now the one method used to convert a `*const c_char` to a Rust
slice of `u8`.
Many more details, including newly deprecated methods, can be found linked in
the RFC. This is a:
[breaking-change]
Closes#20444
The previous scheme made it possible for another user/attacker to cause the
temporary directory creation scheme to panic. All you needed to know was the pid
of the process you wanted to target ('other_pid') and the suffix it was using
(let's pretend it's 'sfx') and then code such as this would, in essence, DOS it:
for i in range(0u, 1001) {
let tp = &Path::new(format!("/tmp/rs-{}-{}-sfx", other_pid, i));
match fs::mkdir(tp, io::USER_RWX) { _ => () }
}
Since the scheme retried only 1000 times to create a temporary directory before
dying, the next time the attacked process called TempDir::new("sfx") after that
would typically cause a panic. Of course, you don't necessarily need an attacker
to cause such a DOS: creating 1000 temporary directories without closing any of
the previous would be enough to DOS yourself.
This patch broadly follows the OpenBSD implementation of mkstemp. It uses the
operating system's random number generator to produce random directory names
that are impractical to guess (and, just in case someone manages to do that, it
retries creating the directory for a long time before giving up; OpenBSD
retries INT_MAX times, although 1<<31 seems enough to thwart even the most
patient attacker).
As a small additional change, this patch also makes the argument that
TempDir::new takes a prefix rather than a suffix. This is because 1) it more
closely matches what mkstemp and friends do 2) if you're going to have a
deterministic part of a filename, you really want it at the beginning so that
shell completion is useful.
* The `sync` module is stable
* The `sync::mpsc` module is stable
* The `Sender::send` method is stable.
* The `Once::doit` method is now removed.
* Deprecated atomic initializers are removed.
* Renamed atomic initializers are now stable.
cc #19260
The casing transformations are left unstable (it is highly likely to be better to adopt the proper non-1-to-1 case mappings, per #20333) as are `is_xid_*`.
I've got a little todo list in the last commit of things I thought about/was told about that I haven't yet handled (I'd also like some feedback).
This "reexports" all the functionality of `core::char::CharExt` as
methods on `unicode::u_char::UnicodeChar` (renamed to `CharExt`).
Imports may need to be updated (one now just imports
`unicode::CharExt`, or `std::char::CharExt` rather than two traits from
either), so this is a
[breaking-change]
TODOs:
- ~~Entry is still `<'a, K, V>` instead of `<'a, O, V>`~~
- ~~BTreeMap is still outstanding~~.
- ~~Transform appropriate things into `.entry(...).get().or_else(|e| ...)`~~
Things that make me frowny face:
- I'm not happy about the fact that this `clone`s the key even when it's already owned.
- With small keys (e.g. `int`s), taking a reference seems wasteful.
r? @Gankro
cc: @cgaebel
This removes a large array of deprecated functionality, regardless of how
recently it was deprecated. The purpose of this commit is to clean out the
standard libraries and compiler for the upcoming alpha release.
Some notable compiler changes were to enable warnings for all now-deprecated
command line arguments (previously the deprecated versions were silently
accepted) as well as removing deriving(Zero) entirely (the trait was removed).
The distribution no longer contains the libtime or libregex_macros crates. Both
of these have been deprecated for some time and are available externally.
closes#20486closes#20474closes#20441
[breaking-change]
The `Index[Mut]` traits now have one less input parameter, as the return type of the indexing operation is an associated type. This breaks all existing implementations.
---
binop traits (`Add`, `Sub`, etc) now have an associated type for their return type. Also, the RHS input parameter now defaults to `Self` (except for the `Shl` and `Shr` traits). For example, the `Add` trait now looks like this:
``` rust
trait Add<Rhs=Self> {
type Output;
fn add(self, Rhs) -> Self::Output;
}
```
The `Neg` and `Not` traits now also have an associated type for their return type.
This breaks all existing implementations of these traits.
---
Affected traits:
- `Iterator { type Item }`
- `IteratorExt` no input/output types, uses `<Self as Iterator>::Item` in its methods
- `DoubleEndedIterator` no input/output types, uses `<Self as Iterator>::Item` in its methods
- `DoubleEndedIteratorExt` no input/output types, uses `<Self as Iterator>::Item` in its methods
- `RandomAccessIterator` no input/output types
- `ExactSizeIterator` no input/output types, uses `<Self as Iterator>::Item` in its methods
This breaks all the implementations of these traits.
The `make_hash` function is used to prevent hashes of non-empty
buckets to collide with `EMPTY_HASH = 0u64`. Ideally this function
also preserve the uniform distribution of hashes and is cheap to
compute.
The new implementation reduces the input hash size by one bit, simply
by setting the most significant bit. This obviously prevent output
hashes to collide with `EMPTY_HASH` and guarantees that the uniform
distribution is preserved. Moreover, the new function is simpler (no
comparisons, just an OR) and (under the same assumptions as the old
function, i.e. only the least significant bit will contribute to the
bucket index) no additional collisions are caused.
This modifies `Parser::eat_lt` to always split up `<<`s, instead of doing so only when a lifetime name followed or the `force` parameter (now removed) was `true`. This is because `Foo<<TYPE` is now a valid start to a type, whereas previously only `Foo<<LIFETIME` was valid.
This is a [breaking-change]. Change code that looks like this:
```rust
let x = foo as bar << 13;
```
to use parentheses, like this:
```rust
let x = (foo as bar) << 13;
```
Closes#17362.
This commit is an implementation of [RFC 503][rfc] which is a stabilization
story for the prelude. Most of the RFC was directly applied, removing reexports.
Some reexports are kept around, however:
* `range` remains until range syntax has landed to reduce churn.
* `Path` and `GenericPath` remain until path reform lands. This is done to
prevent many imports of `GenericPath` which will soon be removed.
* All `io` traits remain until I/O reform lands so imports can be rewritten all
at once to `std::io::prelude::*`.
This is a breaking change because many prelude reexports have been removed, and
the RFC can be consulted for the exact list of removed reexports, as well as to
find the locations of where to import them.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md
[breaking-change]
Closes#20068
This stabilizes most of libcollections, carefully avoiding sections of API which are being managed in other PRs. APIs which are not stable are marked explicitly unstable with a reason.
Deprecates:
* DList
* rotate_forward
* rotate_backward
* prepend
* insert_when
* insert_ordered
* merge
* VecMap
* update
* update_with_key
* Renames and newtypes the Bitv and BitvSet iterators to match conventions.
* Removes the Copy impl from DList's Iter.
as such this is a
[breaking-change]
This is a [breaking-change]. The new rules require that, for an impl of a trait defined
in some other crate, two conditions must hold:
1. Some type must be local.
2. Every type parameter must appear "under" some local type.
Here are some examples that are legal:
```rust
struct MyStruct<T> { ... }
// Here `T` appears "under' `MyStruct`.
impl<T> Clone for MyStruct<T> { }
// Here `T` appears "under' `MyStruct` as well. Note that it also appears
// elsewhere.
impl<T> Iterator<T> for MyStruct<T> { }
```
Here is an illegal example:
```rust
// Here `U` does not appear "under" `MyStruct` or any other local type.
// We call `U` "uncovered".
impl<T,U> Iterator<U> for MyStruct<T> { }
```
There are a couple of ways to rewrite this last example so that it is
legal:
1. In some cases, the uncovered type parameter (here, `U`) should be converted
into an associated type. This is however a non-local change that requires access
to the original trait. Also, associated types are not fully baked.
2. Add `U` as a type parameter of `MyStruct`:
```rust
struct MyStruct<T,U> { ... }
impl<T,U> Iterator<U> for MyStruct<T,U> { }
```
3. Create a newtype wrapper for `U`
```rust
impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { }
```
Because associated types are not fully baked, which in the case of the
`Hash` trait makes adhering to this rule impossible, you can
temporarily disable this rule in your crate by using
`#![feature(old_orphan_check)]`. Note that the `old_orphan_check`
feature will be removed before 1.0 is released.
This commit is an implementation of [RFC 526][rfc] which is a change to alter
the definition of the old `fmt::FormatWriter`. The new trait, renamed to
`Writer`, now only exposes one method `write_str` in order to guarantee that all
implementations of the formatting traits can only produce valid Unicode.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
One of the primary improvements of this patch is the performance of the
`.to_string()` method by avoiding an almost-always redundant UTF-8 check. This
is a breaking change due to the renaming of the trait as well as the loss of the
`write` method, but migration paths should be relatively easy:
* All usage of `write` should move to `write_str`. If truly binary data was
being written in an implementation of `Show`, then it will need to use a
different trait or an altogether different code path.
* All usage of `write!` should continue to work as-is with no modifications.
* All usage of `Show` where implementations just delegate to another should
continue to work as-is.
[breaking-change]
Closes#20352
This pass performs a second pass of stabilization through the `std::sync`
module, avoiding modules/types that are being handled in other PRs (e.g.
mutexes, rwlocks, condvars, and channels).
The following items are now stable
* `sync::atomic`
* `sync::atomic::ATOMIC_BOOL_INIT` (was `INIT_ATOMIC_BOOL`)
* `sync::atomic::ATOMIC_INT_INIT` (was `INIT_ATOMIC_INT`)
* `sync::atomic::ATOMIC_UINT_INIT` (was `INIT_ATOMIC_UINT`)
* `sync::Once`
* `sync::ONCE_INIT`
* `sync::Once::call_once` (was `doit`)
* C == `pthread_once(..)`
* Boost == `call_once(..)`
* Windows == `InitOnceExecuteOnce`
* `sync::Barrier`
* `sync::Barrier::new`
* `sync::Barrier::wait` (now returns a `bool`)
* `sync::Semaphore::new`
* `sync::Semaphore::acquire`
* `sync::Semaphore::release`
The following items remain unstable
* `sync::SemaphoreGuard`
* `sync::Semaphore::access` - it's unclear how this relates to the poisoning
story of mutexes.
* `sync::TaskPool` - the semantics of a failing task and whether a thread is
re-attached to a thread pool are somewhat unclear, and the
utility of this type in `sync` is question with respect to
the jobs of other primitives. This type will likely become
stable or move out of the standard library over time.
* `sync::Future` - futures as-is have yet to be deeply re-evaluated with the
recent core changes to Rust's synchronization story, and will
likely become stable in the future but are unstable until
that time comes.
[breaking-change]
This commit performs a second pass over the `std::thread_local` module. Most of
the functionality remains explicitly unstable, but the specific actions taken
were:
* `thread_local` is now stable
* `thread_local!` is now stable
* `thread_local::Key` is now stable
* `thread_local::Key::with` is now stable
* `thread_local::Key::destroyed` is deprecated in favor of a more general
`state` function
* `thread_local::Key::state` was added to query the three states that a key can
be in: uninitialized, valid, or destroyed. This function, and the
corresponding `State` enum, are both marked unstable as we may wish to expand
it later on.
* `thread_local::scoped` is entirely unstable. There hasn't been a whole lot of
usage of this module in the standard distribution, so it remains unstable at
this time.
Note that while the structure `Key` is marked stable, it is currently forced to
expose all of its implementation details due to the use of
construction-via-macro. The use of construction-via-macro is currently required
in order to place the `#[thread_local]` attribute on static in a
platform-specific manner. These stability attributes were assigned assuming that
it will be acceptable to tweak the implementation of `Key` in the future.
This patch marks `PartialEq`, `Eq`, `PartialOrd`, and `Ord` as
`#[stable]`, as well as the majorify of manual implementaitons of these
traits. The traits match the [reform RFC](https://github.com/rust-lang/rfcs/pull/439).
In the future, many of the impls should be generalized; see #20063.
However, there is no problem stabilizing the less general impls, since
generalizing later is not a breaking change.
r? @alexcrichton
This patch marks `PartialEq`, `Eq`, `PartialOrd`, and `Ord` as
`#[stable]`, as well as the majorify of manual implementaitons of these
traits. The traits match the [reform
RFC](https://github.com/rust-lang/rfcs/pull/439).
Along the way, two changes are made:
* The recently-added type parameters for `Ord` and `Eq` are
removed. These were mistakenly added while adding them to `PartialOrd`
and `PartialEq`, but they don't make sense given the laws that are
required for (and use cases for) `Ord` and `Eq`.
* More explicit laws are added for `PartialEq` and `PartialOrd`,
connecting them to their associated mathematical concepts.
In the future, many of the impls should be generalized; see
since generalizing later is not a breaking change.
[breaking-change]
The new semantics of this function are that the callbacks are run when the *main
thread* exits, not when all threads have exited. This implies that other threads
may still be running when the `at_exit` callbacks are invoked and users need to
be prepared for this situation.
Users in the standard library have been audited in accordance to these new rules
as well.
Closes#20012
We've long had traits `StrVector` and `VectorVector` providing
`concat`/`connect` and `concat_vec`/`connect_vec` respectively. The
reason for the distinction is that coherence rules did not used to be
robust enough to allow impls on e.g. `Vec<String>` versus `Vec<&[T]>`.
This commit consolidates the traits into a single `SliceConcatExt` trait
provided by `slice` and the preldue (where it replaces `StrVector`,
which is removed.)
[breaking-change]
This commit takes a second pass through the `vec` module to
stabilize its API. The changes are as follows:
**Stable**:
* `dedup`
* `from_raw_parts`
* `insert`
* `into_iter`
* `is_empty`
* `remove`
* `reserve_exact`
* `reserve`
* `retain`
* `swap_remove`
* `truncate`
**Deprecated**:
* `from_fn`, `from_elem`, `grow_fn` and `grow`, all deprecated in
favor of iterators. See https://github.com/rust-lang/rfcs/pull/509
* `partition`, `partitioned`, deprecated in favor of a new, more
general iterator consumer called `partition`.
* `unzip`, deprecated in favor of a new, more general iterator
consumer called `unzip`.
A few remaining methods are left at experimental status.
[breaking-change]
This commit performs a second pass over the `std::string` module, performing the
following actions:
* The name `std::string` is now stable.
* The `String::from_utf8` function is now stable after having been altered to
return a new `FromUtf8Error` structure. The `FromUtf8Error` structure is now
stable as well as its `into_bytes` and `utf8_error` methods.
* The `String::from_utf8_lossy` function is now stable.
* The `String::from_chars` method is now deprecated in favor of `.collect()`
* The `String::from_raw_parts` method is now stable
* The `String::from_str` function remains experimental
* The `String::from_raw_buf` function remains experimental
* The `String::from_raw_buf_len` function remains experimental
* The `String::from_utf8_unchecked` function is now stable
* The `String::from_char` function is now deprecated in favor of
`repeat(c).take(n).collect()`
* The `String::grow` function is now deprecated in favor of
`.extend(repeat(c).take(n)`
* The `String::capacity` method is now stable
* The `String::reserve` method is now stable
* The `String::reserve_exact` method is now stable
* The `String::shrink_to_fit` method is now stable
* The `String::pop` method is now stable
* The `String::as_mut_vec` method is now stable
* The `String::is_empty` method is now stable
* The `IntoString` trait is now deprecated (there are no implementors)
* The `String::truncate` method is now stable
* The `String::insert` method is now stable
* The `String::remove` method is now stable
* The `String::push` method is now stable
* The `String::push_str` method is now stable
* The `String::from_utf16` function is now stable after its error type has now
become an opaque structure to carry more semantic information in the future.
A number of these changes are breaking changes, but the migrations should be
fairly straightforward on a case-by-case basis (outlined above where possible).
[breaking-change]
The methods `from_bits` and `from_bits_truncate` were missing from the
list of generated methods. Didn't see a useful way to abbreviate, so
added with the same docstrings used in the macro definition.
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.
* Both enums already derived `Copy`, but storing them in any
struct/container would prevent implementing `Clone` for said
struct/container even though they should be clonable.
* Also add PartialEq and Eq for good measure.
I've created a patch for #20226, which maps `EEXIST` to the `PathAlreadyExists` error on Unix. To test this, I use `mkdir`, which raises `EEXIST` if the directory already exists.
On Windows, I map `ERROR_ALREADY_EXISTS` to `PathAlreadyExist`, but I am note sure if `mkdir` on Windows raises `ERROR_ALREADY_EXISTS` and do not have a Windows installation handy for testing.
And I noticed another thing. No error seems to map to `IoErrorKind::PathDoesntExist` and I am wondering what the difference to `FileNotFound` is?
The example derived Hash + Eq on a type that was used as *values* for
a hashmap.. for the example to make sense, we have to use a custom *key*
type.
Write a slightly more involved example, still using Vikings, but this
time as key.
I preferred using String over &str here, since that's the typical usage
and we might want to lead users down that path.
The first six commits are from an earlier PR (#19858) and have already been reviewed. This PR makes an awful hack in the compiler to accommodate slices both natively and in the index a range form. After a snapshot we can hopefully add the new Index impls and then we can remove these awful hacks.
r? @nikomatsakis (or anyone who knows the compiler, really)
This commit performs a second pass for stabilization over the `std::ptr` module.
The specific actions taken were:
* The `RawPtr` trait was renamed to `PtrExt`
* The `RawMutPtr` trait was renamed to `PtrMutExt`
* The module name `ptr` is now stable.
* These functions were all marked `#[stable]` with no modification:
* `null`
* `null_mut`
* `swap`
* `replace`
* `read`
* `write`
* `PtrExt::is_null`
* `PtrExt::is_not_null`
* `PtrExt::offset`
* These functions remain unstable:
* `as_ref`, `as_mut` - the return value of an `Option` is not fully expressive
as null isn't the only bad value, and it's unclear
whether we want to commit to these functions at this
time. The reference/lifetime semantics as written are
also problematic in how they encourage arbitrary
lifetimes.
* `zero_memory` - This function is currently not used at all in the
distribution, and in general it plays a broader role in the
"working with unsafe pointers" story. This story is not yet
fully developed, so at this time the function remains
unstable for now.
* `read_and_zero` - This function remains unstable for largely the same
reasons as `zero_memory`.
* These functions are now all deprecated:
* `PtrExt::null` - call `ptr::null` or `ptr::null_mut` instead.
* `PtrExt::to_uint` - use an `as` expression instead.
All of the current std::sync primitives have poisoning enable which means that
when a task fails inside of a write-access lock then all future attempts to
acquire the lock will fail. This strategy ensures that stale data whose
invariants are possibly not upheld are never viewed by other tasks to help
propagate unexpected panics (bugs in a program) among tasks.
Currently there is no way to test whether a mutex or rwlock is poisoned. One
method would be to duplicate all the methods with a sister foo_catch function,
for example. This pattern is, however, against our [error guidelines][errors].
As a result, this commit exposes the fact that a task has failed internally
through the return value of a `Result`.
[errors]: https://github.com/rust-lang/rfcs/blob/master/text/0236-error-conventions.md#do-not-provide-both-result-and-fail-variants
All methods now return a `LockResult<T>` or a `TryLockResult<T>` which
communicates whether the lock was poisoned or not. In a `LockResult`, both the
`Ok` and `Err` variants contains the `MutexGuard<T>` that is being returned in
order to allow access to the data if poisoning is not desired. This also means
that the lock is *always* held upon returning from `.lock()`.
A new type, `PoisonError`, was added with one method `into_guard` which can
consume the assertion that a lock is poisoned to gain access to the underlying
data.
This is a breaking change because the signatures of these methods have changed,
often incompatible ways. One major difference is that the `wait` methods on a
condition variable now consume the guard and return it in as a `LockResult` to
indicate whether the lock was poisoned while waiting. Most code can be updated
by calling `.unwrap()` on the return value of `.lock()`.
[breaking-change]
This commit performs a second pass for stabilization over the `std::ptr` module.
The specific actions taken were:
* The `RawPtr` trait was renamed to `PtrExt`
* The `RawMutPtr` trait was renamed to `MutPtrExt`
* The module name `ptr` is now stable.
* These functions were all marked `#[stable]` with no modification:
* `null`
* `null_mut`
* `swap`
* `replace`
* `read`
* `write`
* `PtrExt::is_null`
* `PtrExt::offset`
* These functions remain unstable:
* `as_ref`, `as_mut` - the return value of an `Option` is not fully expressive
as null isn't the only bad value, and it's unclear
whether we want to commit to these functions at this
time. The reference/lifetime semantics as written are
also problematic in how they encourage arbitrary
lifetimes.
* `zero_memory` - This function is currently not used at all in the
distribution, and in general it plays a broader role in the
"working with unsafe pointers" story. This story is not yet
fully developed, so at this time the function remains
unstable for now.
* `read_and_zero` - This function remains unstable for largely the same
reasons as `zero_memory`.
* These functions are now all deprecated:
* `PtrExt::null` - call `ptr::null` or `ptr::null_mut` instead.
* `PtrExt::to_uint` - use an `as` expression instead.
* `PtrExt::is_not_null` - use `!p.is_null()` instead.
This commit performs a second pass over the `std::string` module, performing the
following actions:
* The name `std::string` is now stable.
* The `String::from_utf8` function is now stable after having been altered to
return a new `FromUtf8Error` structure. The `FromUtf8Error` structure is now
stable as well as its `into_bytes` and `utf8_error` methods.
* The `String::from_utf8_lossy` function is now stable.
* The `String::from_chars` method is now deprecated in favor of `.collect()`
* The `String::from_raw_parts` method is now stable
* The `String::from_str` function remains experimental
* The `String::from_raw_buf` function remains experimental
* The `String::from_raw_buf_len` function remains experimental
* The `String::from_utf8_unchecked` function is now stable
* The `String::from_char` function is now deprecated in favor of
`repeat(c).take(n).collect()`
* The `String::grow` function is now deprecated in favor of
`.extend(repeat(c).take(n)`
* The `String::capacity` method is now stable
* The `String::reserve` method is now stable
* The `String::reserve_exact` method is now stable
* The `String::shrink_to_fit` method is now stable
* The `String::pop` method is now stable
* The `String::as_mut_vec` method is now stable
* The `String::is_empty` method is now stable
* The `IntoString` trait is now deprecated (there are no implementors)
* The `String::truncate` method is now stable
* The `String::insert` method is now stable
* The `String::remove` method is now stable
* The `String::push` method is now stable
* The `String::push_str` method is now stable
* The `String::from_utf16` function is now stable after its error type has now
become an opaque structure to carry more semantic information in the future.
A number of these changes are breaking changes, but the migrations should be
fairly straightforward on a case-by-case basis (outlined above where possible).
[breaking-change]
This commit is a second pass stabilization for the `std::comm` module,
performing the following actions:
* The entire `std::comm` module was moved under `std::sync::mpsc`. This movement
reflects that channels are just yet another synchronization primitive, and
they don't necessarily deserve a special place outside of the other
concurrency primitives that the standard library offers.
* The `send` and `recv` methods have all been removed.
* The `send_opt` and `recv_opt` methods have been renamed to `send` and `recv`.
This means that all send/receive operations return a `Result` now indicating
whether the operation was successful or not.
* The error type of `send` is now a `SendError` to implement a custom error
message and allow for `unwrap()`. The error type contains an `into_inner`
method to extract the value.
* The error type of `recv` is now `RecvError` for the same reasons as `send`.
* The `TryRecvError` and `TrySendError` types have had public reexports removed
of their variants and the variant names have been tweaked with enum
namespacing rules.
* The `Messages` iterator is renamed to `Iter`
This functionality is now all `#[stable]`:
* `Sender`
* `SyncSender`
* `Receiver`
* `std::sync::mpsc`
* `channel`
* `sync_channel`
* `Iter`
* `Sender::send`
* `Sender::clone`
* `SyncSender::send`
* `SyncSender::try_send`
* `SyncSender::clone`
* `Receiver::recv`
* `Receiver::try_recv`
* `Receiver::iter`
* `SendError`
* `RecvError`
* `TrySendError::{mod, Full, Disconnected}`
* `TryRecvError::{mod, Empty, Disconnected}`
* `SendError::into_inner`
* `TrySendError::into_inner`
This is a breaking change due to the modification of where this module is
located, as well as the changing of the semantics of `send` and `recv`. Most
programs just need to rename imports of `std::comm` to `std::sync::mpsc` and
add calls to `unwrap` after a send or a receive operation.
[breaking-change]
This stabilizes most methods on `&str` working with patterns in a way that is forwards-compatible with a generic string pattern matching API:
- Methods that are using the primary name for their operation are marked as `#[stable]`, as they can be upgraded to a full `Pattern` API later without existing code breaking. Example: `contains(&str)`
- Methods that are using a more specific name in order to not clash with the primary one are marked as `#[unstable]`, as they will likely be removed once their functionality is merged into the primary one. Example: `contains_char<C: CharEq>(C)`
- The method docs got changed to consistently refer to the pattern types as a pattern.
- Methods whose names do not match in the context of the more generic API got renamed. Example: `trim_chars -> trim_matches`
Additionally, all methods returning iterators got changed to return unique new types with changed names in accordance with the new naming guidelines.
See also https://github.com/rust-lang/rfcs/pull/528
Due to some deprecations and type changes, this is a
[breaking-change]
All of the current std::sync primitives have poisoning enable which means that
when a task fails inside of a write-access lock then all future attempts to
acquire the lock will fail. This strategy ensures that stale data whose
invariants are possibly not upheld are never viewed by other tasks to help
propagate unexpected panics (bugs in a program) among tasks.
Currently there is no way to test whether a mutex or rwlock is poisoned. One
method would be to duplicate all the methods with a sister foo_catch function,
for example. This pattern is, however, against our [error guidelines][errors].
As a result, this commit exposes the fact that a task has failed internally
through the return value of a `Result`.
[errors]: https://github.com/rust-lang/rfcs/blob/master/text/0236-error-conventions.md#do-not-provide-both-result-and-fail-variants
All methods now return a `LockResult<T>` or a `TryLockResult<T>` which
communicates whether the lock was poisoned or not. In a `LockResult`, both the
`Ok` and `Err` variants contains the `MutexGuard<T>` that is being returned in
order to allow access to the data if poisoning is not desired. This also means
that the lock is *always* held upon returning from `.lock()`.
A new type, `PoisonError`, was added with one method `into_guard` which can
consume the assertion that a lock is poisoned to gain access to the underlying
data.
This is a breaking change because the signatures of these methods have changed,
often incompatible ways. One major difference is that the `wait` methods on a
condition variable now consume the guard and return it in as a `LockResult` to
indicate whether the lock was poisoned while waiting. Most code can be updated
by calling `.unwrap()` on the return value of `.lock()`.
[breaking-change]
This commit is an implementation of [RFC 503][rfc] which is a stabilization
story for the prelude. Most of the RFC was directly applied, removing reexports.
Some reexports are kept around, however:
* `range` remains until range syntax has landed to reduce churn.
* `Path` and `GenericPath` remain until path reform lands. This is done to
prevent many imports of `GenericPath` which will soon be removed.
* All `io` traits remain until I/O reform lands so imports can be rewritten all
at once to `std::io::prelude::*`.
This is a breaking change because many prelude reexports have been removed, and
the RFC can be consulted for the exact list of removed reexports, as well as to
find the locations of where to import them.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md
[breaking-change]
Closes#20068
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]
We have the technology: no longer do you need to write closures to use `format_args!`.
This is a `[breaking-change]`, as it forces you to clean up old hacks - if you had code like this:
```rust
format_args!(fmt::format, "{} {} {}", a, b, c)
format_args!(|args| { w.write_fmt(args) }, "{} {} {}", x, y, z)
```
change it to this:
```rust
fmt::format(format_args!("{} {} {}", a, b, c))
w.write_fmt(format_args!("{} {} {}", x, y, z))
```
To allow them to be called with `format_args!(...)` directly, several functions were modified to
take `fmt::Arguments` by value instead of by reference. Also, `fmt::Arguments` derives `Copy`
now in order to preserve all usecases that were previously possible.
The methods `from_bits` and `from_bits_truncate` were missing from the
list of generated methods. Didn't see a useful way to abbreviate, so
added with the same docstrings used in the macro definition.
Implements [RFC 486](https://github.com/rust-lang/rfcs/pull/486). Fixes#19908.
* Rename `to_ascii_{lower,upper}` to `to_ascii_{lower,upper}case`, per #14401
* Remove the `Ascii` type and associated traits: `AsciiCast`, `OwnedAsciiCast`, `AsciiStr`, `IntoBytes`, and `IntoString`.
* As a replacement, add `.is_ascii()` to `AsciiExt`, and implement `AsciiExt` for `u8` and `char`.
[breaking-change]
More work on opt-in built in traits. `Send` and `Sync` are not opt-in, `OwnedPtr` renamed to `UniquePtr` and the `Send` and `Sync` traits are now unsafe.
NOTE: This likely needs to be rebased on top of the yet-to-land snapshot.
r? @nikomatsakis
cc #13231
* Both enums already derived `Copy`, but storing them in any
struct/container would prevent implementing `Clone` for said
struct/container even though they should be clonable.
* Also add PartialEq and Eq for good measure.
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]
The example derived Hash + Eq on a type that was used as *values* for
a hashmap.. for the example to make sense, we have to use a custom *key*
type.
Write a slightly more involved example, still using Vikings, but this
time as key.
I preferred using String over &str here, since that's the typical usage
and we might want to lead users down that path.
According to [RFC 344][], methods that return `&[u8]` should have names ending in `bytes`. Though `include_bin!` is a macro not a method, it seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning when it is used.
[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md
[breaking-change]
Rename `FPCategory` to `FpCategory` and `Fp* to `*` in order to adhere to the
naming convention
This is a [breaking-change].
Existing code like this:
```
use std::num::{FPCategory, FPNaN};
```
should be adjusted to this:
```
use std::num::FpCategory as Fp
```
In the following code you can use the constants `Fp::Nan`, `Fp::Normal`, etc.
According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning
when it is used.
[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md
[breaking-change]
Now that #19448 has landed in a snapshot, we can add proper by-value operator overloads for `HashSet`. The behavior of these operator overloads is consistent with rust-lang/rfcs#235.
post-unboxed-closure-conversion. This requires a fair amount of
annoying coercions because all the `map` etc types are defined
generically over the `F`, so the automatic coercions don't propagate;
this is compounded by the need to use `let` and not `as` due to
stage0. That said, this pattern is to a large extent temporary and
unusual.
cannot use an `as` expression to coerce, so I used a one-off function
instead (this is a no-op in stage0, but in stage1+ it triggers
coercion from the fn pointer to the fn item type).
This commit starts out by consolidating all `str` extension traits into one
`StrExt` trait to be included in the prelude. This means that
`UnicodeStrPrelude`, `StrPrelude`, and `StrAllocating` have all been merged into
one `StrExt` exported by the standard library. Some functionality is currently
duplicated with the `StrExt` present in libcore.
This commit also currently avoids any methods which require any form of pattern
to operate. These functions will be stabilized via a separate RFC.
Next, stability of methods and structures are as follows:
Stable
* from_utf8_unchecked
* CowString - after moving to std::string
* StrExt::as_bytes
* StrExt::as_ptr
* StrExt::bytes/Bytes - also made a struct instead of a typedef
* StrExt::char_indices/CharIndices - CharOffsets was renamed
* StrExt::chars/Chars
* StrExt::is_empty
* StrExt::len
* StrExt::lines/Lines
* StrExt::lines_any/LinesAny
* StrExt::slice_unchecked
* StrExt::trim
* StrExt::trim_left
* StrExt::trim_right
* StrExt::words/Words - also made a struct instead of a typedef
Unstable
* from_utf8 - the error type was changed to a `Result`, but the error type has
yet to prove itself
* from_c_str - this function will be handled by the c_str RFC
* FromStr - this trait will have an associated error type eventually
* StrExt::escape_default - needs iterators at least, unsure if it should make
the cut
* StrExt::escape_unicode - needs iterators at least, unsure if it should make
the cut
* StrExt::slice_chars - this function has yet to prove itself
* StrExt::slice_shift_char - awaiting conventions about slicing and shifting
* StrExt::graphemes/Graphemes - this functionality may only be in libunicode
* StrExt::grapheme_indices/GraphemeIndices - this functionality may only be in
libunicode
* StrExt::width - this functionality may only be in libunicode
* StrExt::utf16_units - this functionality may only be in libunicode
* StrExt::nfd_chars - this functionality may only be in libunicode
* StrExt::nfkd_chars - this functionality may only be in libunicode
* StrExt::nfc_chars - this functionality may only be in libunicode
* StrExt::nfkc_chars - this functionality may only be in libunicode
* StrExt::is_char_boundary - naming is uncertain with container conventions
* StrExt::char_range_at - naming is uncertain with container conventions
* StrExt::char_range_at_reverse - naming is uncertain with container conventions
* StrExt::char_at - naming is uncertain with container conventions
* StrExt::char_at_reverse - naming is uncertain with container conventions
* StrVector::concat - this functionality may be replaced with iterators, but
it's not certain at this time
* StrVector::connect - as with concat, may be deprecated in favor of iterators
Deprecated
* StrAllocating and UnicodeStrPrelude have been merged into StrExit
* eq_slice - compiler implementation detail
* from_str - use the inherent parse() method
* is_utf8 - call from_utf8 instead
* replace - call the method instead
* truncate_utf16_at_nul - this is an implementation detail of windows and does
not need to be exposed.
* utf8_char_width - moved to libunicode
* utf16_items - moved to libunicode
* is_utf16 - moved to libunicode
* Utf16Items - moved to libunicode
* Utf16Item - moved to libunicode
* Utf16Encoder - moved to libunicode
* AnyLines - renamed to LinesAny and made a struct
* SendStr - use CowString<'static> instead
* str::raw - all functionality is deprecated
* StrExt::into_string - call to_string() instead
* StrExt::repeat - use iterators instead
* StrExt::char_len - use .chars().count() instead
* StrExt::is_alphanumeric - use .chars().all(..)
* StrExt::is_whitespace - use .chars().all(..)
Pending deprecation -- while slicing syntax is being worked out, these methods
are all #[unstable]
* Str - while currently used for generic programming, this trait will be
replaced with one of [], deref coercions, or a generic conversion trait.
* StrExt::slice - use slicing syntax instead
* StrExt::slice_to - use slicing syntax instead
* StrExt::slice_from - use slicing syntax instead
* StrExt::lev_distance - deprecated with no replacement
Awaiting stabilization due to patterns and/or matching
* StrExt::contains
* StrExt::contains_char
* StrExt::split
* StrExt::splitn
* StrExt::split_terminator
* StrExt::rsplitn
* StrExt::match_indices
* StrExt::split_str
* StrExt::starts_with
* StrExt::ends_with
* StrExt::trim_chars
* StrExt::trim_left_chars
* StrExt::trim_right_chars
* StrExt::find
* StrExt::rfind
* StrExt::find_str
* StrExt::subslice_offset
Alex Crichton
Jorge Aparicio
Felix S. Klock II
Brian Anderson
Nick Cameron
Aaron Turon
bors
Joseph Crail
Corey Richardson
Piotr Czarnecki
Sean McArthur
Niko Matsakis
Dylan Ede
Michael Neumann
klutzy
Valerii Hiora
Huon Wilson
Peter Atashian
Keegan McAllister
Steve Klabnik
FakeKane
Andrew Paseltiner
Simonas Kazlauskas
Laurence Tratt
Zbigniew Siciarz
Ben Foppa
ville-h
Tshepang Lekhonkhobe
Akos Kiss
Andrea Canciani
Alexis Beingessner
Corey Farwell
Eric Allen
Murarth
arturo
Nicholas Bishop
Eduard Burtescu
Flavio Percoco
Ivan Petkov
Florian Hahn
Marvin Löbel
Adolfo Ochagavía
Simon Sapin
P1start
Steven Fackler
Chase Southwood
bluss
Tobias Bucher
Chris Wong
Florian Wilkens