Long ago we discovered that threads which outlive main and then exit while the
rest of the program is exiting causes Windows to hang (#20704). That's what was
happening in this test so let's just not run this test any more.
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
Changed the description of the `make_mut` copy-on-write behaviour in arc.rs
The sentence "doesn't have one strong reference and no weak references." is a
hard to understand double negative, which can be much more easily explained.
This was accidentally introduced in
7e2ffc7090a70fe8c77a0e03fcec3cb1387141f2,
b44ee371b8beea77aa1364460acbba14a8516559 and
36ba96ea3cfef575ddc5eea7754a1b70b50e2080.
This hairy conditional doesn't need to be so. It _does_ need to be a
thin pointer, otherwise, it will fail to compile, so let's pull that out
into a temporary for future readers of the source.
/cc @nrc @SimonSapin @Gankro @durka , who brought this up on IRC
This hairy conditional doesn't need to be so. It _does_ need to be a
thin pointer, otherwise, it will fail to compile, so let's pull that out
into a temporary for future readers of the source.
Also, after a discussion with @pnkfelix and @gankro, we don't need these
null checks anymore, as zero-on-drop has been gone for a while now.
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```rust
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
Also to mention, I made those impls stable, and I don't know whether they should be actually stable from the beginning. Please tell me if this should be feature-gated.
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
This change has two consequences:
1. It makes `Arc<T>` and `Rc<T>` covariant in `T`.
2. It causes the compiler to reject code that was unsound with respect
to dropck. See compile-fail/issue-29106.rs for an example of code that
no longer compiles. Because of this, this is a [breaking-change].
Fixes#29037.
Fixes#29106.
The text says it's a vector of floats, but the code actually uses a vector of integers. The type of the Vec doesn't really matter, so I just cut it from the text.
These common traits were left off originally by accident from these smart
pointers, and a past attempt (#26008) to add them was later reverted (#26160)
due to unexpected breakge (#26096) occurring. The specific breakage in worry is
the meaning of this return value changed:
let a: Box<Option<T>> = ...;
a.as_ref()
Currently this returns `Option<&T>` but after this change it will return
`&Option<T>` because the `AsRef::as_ref` method shares the same name as
`Option::as_ref`. A [crater report][crater] of this change, however, has shown
that the fallout of this change is quite minimal. These trait implementations
are "the right impls to add" to these smart pointers and would enable various
generalizations such as those in #27197.
[crater]: https://gist.github.com/anonymous/0ba4c3512b07641c0f99
This commit is a breaking change for the above reasons mentioned, and the
mitigation strategies look like any of:
Option::as_ref(&a)
a.as_ref().as_ref()
(*a).as_ref()
These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:
* The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
* The `core::atomic` module now lives in `core::sync::atomic`. The `core::sync` module is otherwise empty, but ripe for expansion!
* The `core::prelude::v1` module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
* Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the `flt2dec` module is now used for "privacy").
After this commit, the remaining large unstable functionality specific to libcore is:
* `raw`, `intrinsics`, `nonzero`, `array`, `panicking`, `simd` -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
* `num::Float` - this extension trait for floats needs to be audited for functionality (much of that is happening in #27823) and may also want to be renamed to `FloatExt` or `F32Ext`/`F64Ext`.
* Should the extension traits for primitives be stabilized in libcore?
I believe other unstable pieces are not isolated to just libcore but also affect the standard library.
cc #27701
