Add `Box::clone_from_ref` and similar under `feature(clone_from_ref)`
Tracking issue: https://github.com/rust-lang/rust/issues/149075
Accepted ACP: https://github.com/rust-lang/libs-team/issues/483
This PR implements `clone_from_ref` (and `try_*` and `_*in` variants), to get a `Box<T>`, `Arc<T>`, or `Rc<T>` by cloning from a `&T` where `T: CloneToUninit`.
The "Implement..." commits replace some ad-hoc conversions with `clone_from_ref` variants, which can be split out to a separate PR if desired.
This PR will conflict with https://github.com/rust-lang/rust/pull/148769 due to usage of `Layout::dangling` (which that PR is renaming to `dangling_ptr`), so they should not be rolled up together, and the one which merges later will need to be amended.
Warn against calls which mutate an interior mutable `const`-item
## `const_item_interior_mutations`
~~`interior_mutable_const_item_mutations`~~
~~`suspicious_mutation_of_interior_mutable_consts`~~
*warn-by-default*
The `const_item_interior_mutations` lint checks for calls which mutates an interior mutable const-item.
### Example
```rust
use std::sync::Once;
const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
// never modify it-self on use, should be a `static`
// instead for shared use
fn init() {
INIT.call_once(|| {
println!("Once::call_once first call");
});
}
```
```text
warning: mutation of an interior mutable `const` item with call to `call_once`
--> a.rs:11:5
|
11 | INIT.call_once(|| {
| ^---
| |
| _____`INIT` is a interior mutable `const` item of type `std::sync::Once`
| |
12 | | println!("Once::call_once first call");
13 | | });
| |______^
|
= note: each usage of a `const` item creates a new temporary
= note: only the temporaries and never the original `const INIT` will be modified
= help: for more details on interior mutability see <https://doc.rust-lang.org/reference/interior-mutability.html>
= note: `#[warn(const_item_interior_mutations)]` on by default
help: for a shared instance of `INIT`, consider making it a `static` item instead
|
6 - const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
6 + static INIT: Once = Once::new(); // using `INIT` will always create a temporary and
|
```
### Explanation
Calling a method which mutates an interior mutable type has no effect as const-item are essentially inlined wherever they are used, meaning that they are copied directly into the relevant context when used rendering modification through interior mutability ineffective across usage of that const-item.
The current implementation of this lint only warns on significant `std` and `core` interior mutable types, like `Once`, `AtomicI32`, ... this is done out of prudence and may be extended in the future.
----
This PR is an targeted alternative to rust-lang/rust#132146. It avoids false-positives by adding an internal-only attribute `#[rustc_should_not_be_called_on_const_items]` on methods and functions that mutates an interior mutale type through a shared reference (mutable refrences are already linted by the `const_item_mutation` lint).
It should also be noted that this is NOT an uplift of the more general [`clippy::borrow_interior_mutable_const`](https://rust-lang.github.io/rust-clippy/master/index.html#/borrow_interior_mutable_const) lint, which is a much more general lint regarding borrow of interior mutable types, but has false-positives that are completly avoided by this lint.
A simple [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%28%3F-i%29const+%5Ba-zA-Z0-9_%5D*%3A+Once%2F&type=code) reveals many instance where the user probably wanted to use a `static`-item instead.
----
````@rustbot```` labels +I-lang-nominated +T-lang
cc ````@traviscross````
r? compiler
Fixes [IRLO - Forbidding creation of constant mutexes, etc](https://internals.rust-lang.org/t/forbidding-creation-of-constant-mutexes-etc/19005)
Fixes https://github.com/rust-lang/rust/issues/132028
Fixes https://github.com/rust-lang/rust/issues/40543
std: sys: fs: uefi: Fix FileAttr size
- The underlying file size is represented by file_size field. The size field is just the size of structure since it is a C DST.
- Fixes bug created in https://github.com/rust-lang/rust/pull/148970
``@rustbot`` label +O-UEFI
sgx: avoid unnecessarily creating a slice
Cc ``@jethrogb`` -- no idea why this created a slice only to directly convert it back to a raw pointer, but we can avoid this and in fact make the entire function safe. I didn't change the function signature (it's still an `unsafe fn`) as I know nothing about the surrounding code.
fs: Run file lock tests on all platforms that support it
There are a number of platforms that support file locking but aren't getting tested. Synchronize the list and mark the tests `should_panic` otherwise, to make sure they get updated if more platforms add locking support.
The supported platform list comes from https://github.com/rust-lang/rust/blob/07bdbaedc63094281483c40a88a1a8f2f8ffadc5/library/std/src/sys/fs/unix.rs#L1291-L1308. Windows also supports file locks, all other platforms are unsupported.
Add missing trailing period to RustDoc for fn create_dir().
Documentation for other functions in the standard library RustDocs have a trailing period at the end of the first sentence, e.g. `create_dir_all()` and `create_buffered()` have the trailing period, but the first line of documentation for `fn create_dir()` lacks a trailing period. This PR adds the missing period.
- The underlying file size is represented by file_size field. The size
field is just the size of structure since it is a C DST.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rather than skipping the tests, make sure that they fail. This ensures
that if file locking support is added for more platforms in the future,
the tests don't wind up quietly skipped.
819247f1 changed <str as Debug>::fmt such that it does not escape single
quotes, but neglected to apply the same choice to OsString. This commit
does that.
std: move `kernel_copy` to `sys`
Part of rust-lang/rust#117276.
The current organisation of the `kernel_copy` mechanism used to specialise `io::copy` on Linux necessitated circular links between the `io::copy` module and the implementation in `sys::pal::unix::kernel_copy`, as well as presenting an exception to the tidy PAL rule that forbids OS-based `#[cfg]`s outside of `sys` and `os`.
This PR fixes this by moving `kernel_copy` to `sys` (as per rust-lang/rust#117276) and returning a `CopyState` from that function specifying whether `io::copy` should use its fallback. The `kernel_copy` function on other platforms just unconditionally returns `CopyState::Fallback`.
add must_use to extract_if methods
Also, mention the `.for_each(drop)` pattern in the documentation. One can't always use `retain` with a negated predicate as that does not have a range argument.
r? `@the8472`
Stabilize vec_into_raw_parts
This stabilizes `Vec::into_raw_parts()` and `String::into_raw_parts()` per FCP in https://github.com/rust-lang/rust/issues/65816#issuecomment-3517630971. While this _does not_ stabilize `Vec::into_parts()`, I fixed up the examples that said they were waiting for `vec_into_raw_parts`. As `Vec::from_parts()` and `Vec::into_parts()` are covered by the same feature `box_vec_non_null`, any doctest that uses `Vec::from_parts()` can also use `Vec::into_parts()` (and same for allocator-aware versions).
Closesrust-lang/rust#65816
``@rustbot`` modify labels: +T-libs-api
uefi: fs: Add file times plumbing
- Add plumbing to allow conversions to and from UEFI Time to Rust SystemTime.
- Also add FileTimes implementation.
cc `@nicholasbishop`
r? `@petrochenkov`
add missing s390x target feature to std detect test
Fix an oversight from https://github.com/rust-lang/rust/pull/145656, where the `is_s390x_feature_detected!` macro and some target features were stabilized, but other target features remain unstable under a new target feature name.
I tested this locally using a `stage1` build on the test file with the `s390x-unknown-linux-gnu` target.
cc ```@uweigand```
r? ```@Amanieu``` (or whoever really)
std: support `RwLock` and thread parking on TEEOS
Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms.
CC ``@petrochenkov`` ``@Sword-Destiny``
bors