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 takes building `librustc/lib.rs` from using 696 MB to 588 (`rustc --no-trans`), and 1.99 GB to 1.87 (`rustc -O`). It also reduces `sty` down to 32 bytes on platforms with 64-bit pointers, at the expense of some more side-tables in `ctxt`. I'm sure there's more gains to be had from reducing the size of the side tables (e.g. by making the actual things they're storing smaller).
r? @nikomatsakis
This cuts memory use dramatically from the previous commit, and reduces
use overall. E.g. the memory usage of `rustc -O librustc/lib.rs` seems
to drop 100MB from 1.98GB to 1.88GB (on one run anyway).
This extends the nullable enum opt to traverse beyond just the first level to find possible fields to use as the discriminant. So now, it'll work through structs, tuples, and fixed sized arrays. This also introduces a new lang item, NonZero, that you can use to wrap raw pointers or integral types to indicate to rustc that the underlying value is known to never be 0/NULL. We then use this in Vec, Rc and Arc to have them also benefit from the nullable enum opt.
As per https://github.com/rust-lang/rfcs/pull/499 NonZero is not exposed via the `libstd` facade.
```
x86_64 Linux:
T Option<T> (Before) Option<T> (After)
----------------------------------------------------------------------------------
Vec<int> 24 32 24
String 24 32 24
Rc<int> 8 16 8
Arc<int> 8 16 8
[Box<int>, ..2] 16 24 16
(String, uint) 32 40 32
```
Fixes#19419.
Fixes#13194.
Fixes#9378.
Fixes#7576.
Using the current directory may not always be appropriate, for example in
the case where it will unnecessarily trigger a backup to be made.
The only risk with this change is that systems might not have a mktemp.
I am not aware of such a system, but have not tested on Windows. It is
working on a basic Ubuntu and OS X installation.
This PR deprecates the `DList::ListInsertion` trait, in accordance with rust-lang/rfcs#509. The functions which were previously part of the ListInsertion impl for `DList::IterMut` have been moved to be inherent methods on the iterator itself, and appropriate doctests have been added.
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.
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]
closes#19141closes#20193closes#20228
---
Currently whenever we encounter `let f = || {/* */}`, we *always* type check the RHS as a *boxed* closure. This is wrong when the RHS is `move || {/* */}` (because boxed closures can't capture by value) and generates all sort of badness during trans (see issues above). What we *should* do is always type check `move || {/* */}` as an *unboxed* closure, but ~~I *think* (haven't tried)~~ (2) this is not feasible right now because we have a limited form of kind (`Fn` vs `FnMut` vs `FnOnce`) inference that only works when there is an expected type (1).
In this PR, I've chosen to generate a type error whenever `let f = move || {/* */}` is encountered. The error asks the user to annotate the kind of the unboxed closure (e.g. `move |:| {/* */}`). Once annotated, the compiler will type check the RHS as an unboxed closure which is what the user wants.
r? @nikomatsakis
(1) AIUI it only triggers in this scenario:
``` rust
fn is_uc<F>(_: F) where F: FnOnce() {}
fn main() {
is_uc(|| {}); // type checked as unboxed closure with kind `FnOnce`
}
```
(2) I checked, and it's not possible because `check_unboxed_closure` expects a `kind` argument, but we can't supply that argument in this case (i.e. `let f = || {}`, what's the kind?). We could force the `FnOnce` kind in that case, but that's ad hoc. We should try to infer the kind depending on how the closure is used afterwards, but there is no inference mechanism to do that (at least, not right now).
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
