| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Conflicts:
src/libcore/ops.rs
src/librustc_typeck/astconv.rs
src/libstd/io/mem.rs
src/libsyntax/parse/lexer/mod.rs
|
|
|
|
Conflicts:
src/liballoc/boxed.rs
src/librustc/middle/traits/error_reporting.rs
src/libstd/sync/mpsc/mod.rs
|
|
Conflicts:
src/libstd/sync/mpsc/select.rs
|
|
r? @alexcrichton
|
|
Conflicts:
src/libstd/io/mod.rs
|
|
Conflicts:
src/libsyntax/parse/lexer/comments.rs
|
|
Fixes #20943 and adds a test for it
r? @alexcrichton
|
|
|
|
This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
RFC and audited implementations now have the `#[stable]` attribute
* Integers and floats no longer print a suffix
* Smart pointers no longer print details that they are a smart pointer
* Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
`Display` must be implemented. With the loss of `String`, this has moved into
libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
warned about due to warnings being emitted on stage1+
While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.
[breaking-change]
Closes #21436
|
|
|
|
As discussed with @aturon, this PR removes the `Send` bound from `std::error::Error`, allowing us to implement `Error` for error types containing non-`Send` types. Current examples include `PoisonError` and `TryLockError` from `std::sync` which contain a Guard that we don't want sent between tasks.
[breaking-change]
|
|
|
|
|
|
Fixes #20943
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
|
|
|
|
I searched for times when we were hiding functions with # in the documentation,
and fixed them to not use it unless neccesary.
I also made random improvements whenever I changed something. For example,
I changed Example to Examples, for consistency.
Fixes #13423
|
|
expansion now uses `::std::hash::Hash::hash(&*__self_0_0, __arg_0)` instead of
`(*__self_0_0).hash(__arg_0)`
closes #21160
|
|
It's passed to the underlying reader, so uninitialized memory == sad
times.
We might want to shrink the default buffer size as well. 64k is pretty
huge. Java uses 8k by default, and Go uses 4k for reference.
r? @alexcrichton
|
|
|
|
It's passed to the underlying reader, so uninitialized memory == sad
times.
We might want to shrink the default buffer size as well. 64k is pretty
huge. Java uses 8k by default, and Go uses 4k for reference.
|
|
|
|
Change any use of AtomicInt to AtomicIsize and AtomicUint to AtomicUsize
Closes #20893
[breaking-change]
|
|
Change any use of AtomicInt to AtomicIsize and AtomicUint to AtomicUsize
Closes #20893
[breaking-change]
|
|
A derived implementation would not be appropriate for the Buffered types
since the buffer is both huge (64k by default) and full of uninitialized
memory. Instead of printing the whole thing, we display how full it is.
I also altered MultiWriter to make it generic over Writers instead of
taking Box<Writer> trait objects. Box<Writer> implements Writer so
existing use cases should continue to work, and this enables a more
useful Show implementation in applicable cases.
The change to MultiWriter may break code that uses it, but any fixes
should be easy.
[breaking-change]
|
|
Better iOS support
Reviewed-by: alexcrichton
|
|
Now it is possible to run tests on a jailbroken device
|
|
This gets rid of the 'experimental' level, removes the non-staged_api
case (i.e. stability levels for out-of-tree crates), and lets the
staged_api attributes use 'unstable' and 'deprecated' lints.
This makes the transition period to the full feature staging design
a bit nicer.
|
|
|
|
Conflicts:
src/libcollections/vec.rs
src/libcore/fmt/mod.rs
src/librustc/lint/builtin.rs
src/librustc/session/config.rs
src/librustc_trans/trans/base.rs
src/librustc_trans/trans/context.rs
src/librustc_trans/trans/type_.rs
src/librustc_typeck/check/_match.rs
src/librustdoc/html/format.rs
src/libsyntax/std_inject.rs
src/libsyntax/util/interner.rs
src/test/compile-fail/mut-pattern-mismatched.rs
|
|
Conflicts:
src/libserialize/lib.rs
|
|
|
|
|
|
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 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]
|
|
Conflicts:
src/libsyntax/parse/parser.rs
|
|
Conflicts:
src/libcore/array.rs
src/libcore/cell.rs
src/libcore/prelude.rs
src/libstd/path/posix.rs
src/libstd/prelude/v1.rs
src/test/compile-fail/dst-sized-trait-param.rs
|
|
Conflicts:
src/libcollections/lib.rs
src/librustc/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
|
|
Prevents breaking down `$name` tokens into separate `$` and `name`.
Reports unknown macro variables.
Fixes #18775
Fixes #18839
Fixes #15640
|
|
Conflicts:
src/librbml/lib.rs
src/libserialize/json_stage0.rs
src/libserialize/serialize_stage0.rs
src/libsyntax/ast.rs
src/libsyntax/ext/deriving/generic/mod.rs
src/libsyntax/parse/token.rs
|
|
Conflicts:
src/compiletest/runtest.rs
src/libcore/fmt/mod.rs
src/libfmt_macros/lib.rs
src/libregex/parse.rs
src/librustc/middle/cfg/construct.rs
src/librustc/middle/dataflow.rs
src/librustc/middle/infer/higher_ranked/mod.rs
src/librustc/middle/ty.rs
src/librustc_back/archive.rs
src/librustc_borrowck/borrowck/fragments.rs
src/librustc_borrowck/borrowck/gather_loans/mod.rs
src/librustc_resolve/lib.rs
src/librustc_trans/back/link.rs
src/librustc_trans/save/mod.rs
src/librustc_trans/trans/base.rs
src/librustc_trans/trans/callee.rs
src/librustc_trans/trans/common.rs
src/librustc_trans/trans/consts.rs
src/librustc_trans/trans/controlflow.rs
src/librustc_trans/trans/debuginfo.rs
src/librustc_trans/trans/expr.rs
src/librustc_trans/trans/monomorphize.rs
src/librustc_typeck/astconv.rs
src/librustc_typeck/check/method/mod.rs
src/librustc_typeck/check/mod.rs
src/librustc_typeck/check/regionck.rs
src/librustc_typeck/collect.rs
src/libsyntax/ext/format.rs
src/libsyntax/ext/source_util.rs
src/libsyntax/ext/tt/transcribe.rs
src/libsyntax/parse/mod.rs
src/libsyntax/parse/token.rs
src/test/run-pass/issue-8898.rs
|
|
|
|
|
|
|
|
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]
|
|
`#[old_impl_check]`.
|
