Commit Graph

4061 Commits

Author SHA1 Message Date
Thayne McCombs
63a7fdf61b Fix types in documentation for Alignment::as_usize and Alignmnet::as_nonzero 2022-10-16 23:44:06 -06:00
Matthias Krüger
0602d6484b
Rollup merge of #103109 - RalfJung:phantom-data-impl, r=thomcc
PhantomData: inline a macro that is used only once

I suspect this macro used to have more uses, but right now it just obfuscates the code.
2022-10-16 22:36:06 +02:00
Matthias Krüger
bdfc262742
Rollup merge of #103102 - H4x5:len_utf16_docs, r=scottmcm
Clarify the possible return values of `len_utf16`

`char::len_utf16` always return 1 or 2. Clarify this in the docs, in the same way as `char::len_utf8`.
2022-10-16 22:36:06 +02:00
Sky
a6372525ce
Clarify the possible return values of len_utf16 2022-10-16 11:06:19 -04:00
Ralf Jung
ddd5e983d1 PhantomData: inline a macro that is used only once 2022-10-16 10:37:51 +02:00
Yuki Okushi
166f664037
Rollup merge of #102023 - SUPERCILEX:maybeuninit-transpose, r=scottmcm
Add MaybeUninit array transpose From impls

See discussion in https://github.com/rust-lang/rust/pull/101179 and https://github.com/rust-lang/rust/issues/96097. I believe this solution offers the simplest implementation with minimal future API regret.

`@RalfJung` mind doing a correctness review?
2022-10-16 11:41:12 +09:00
Yuki Okushi
cbc0a73c95
Rollup merge of #101717 - Pointerbender:unsafecell-memory-layout, r=Amanieu
Add documentation about the memory layout of `UnsafeCell<T>`

The documentation for `UnsafeCell<T>` currently does not make any promises about its memory layout. This PR adds this documentation, namely that the memory layout of `UnsafeCell<T>` is the same as the memory layout of its inner `T`.

# Use case
Without this layout promise, the following cast would not be legally possible:

```rust
fn example<T>(ptr: *mut T) -> *const UnsafeCell<T> {
  ptr as *const UnsafeCell<T>
}
```

A use case where this can come up involves FFI. If Rust receives a pointer over a FFI boundary which provides shared read-write access (with some form of custom synchronization), and this pointer is managed by some Rust struct with lifetime `'a`, then it would greatly simplify its (internal) API and safety contract if a `&'a UnsafeCell<T>` can be created from a raw FFI pointer `*mut T`. A lot of safety checks can be done when receiving the pointer for the first time through FFI (non-nullness, alignment, initialize uninit bytes, etc.) and these properties can then be encoded into the `&UnsafeCell<T>` type. Without this documentation guarantee, this is not legal today outside of the standard library.

# Caveats
Casting in the opposite direction is still not valid, even with this documentation change:

```rust
fn example2<T>(ptr: &UnsafeCell<T>) -> &mut T {
  let t = ptr as *const UnsafeCell<T> as *mut T;
  unsafe { &mut *t }
}
```

This is because the only legal way to obtain a mutable pointer to the contents of the shared reference is through [`UnsafeCell::get`](https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html#method.get) and [`UnsafeCell::raw_get`](https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html#method.raw_get). Although there might be a desire to also make this legal at some point in the future, that part is outside the scope of this PR. Also see this relevant [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/transmuting.20.26.20-.3E.20.26mut).

# Alternatives
Instead of adding a new documentation promise, it's also possible to add a new method to `UnsafeCell<T>` with signature `pub fn from_ptr_bikeshed(ptr: *mut T) -> *const UnsafeCell<T>` which indirectly only allows one-way casting to `*const UnsafeCell<T>`.
2022-10-16 11:41:12 +09:00
Alex Saveau
393434c29e
Add MaybeUninit array transpose impls
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2022-10-15 15:57:19 -07:00
bors
8147e6e427 Auto merge of #103069 - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #102092 (refactor: use grep -E/-F instead of fgrep/egrep)
 - #102781 (Improved documentation for `std::io::Error`)
 - #103017 (Avoid dropping TLS Key on sgx)
 - #103039 (checktools: fix comments)
 - #103045 (Remove leading newlines from integer primitive doc examples)
 - #103047 (Update browser-ui-test version to fix some flaky tests)
 - #103054 (Clean up rust-logo rustdoc GUI test)
 - #103059 (Fix `Duration::{try_,}from_secs_f{32,64}(-0.0)`)
 - #103067 (More alphabetical sorting)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-10-14 22:56:53 +00:00
Matthias Krüger
03a521b4fe
Rollup merge of #103059 - beetrees:duration-from-negative-zero, r=thomcc
Fix `Duration::{try_,}from_secs_f{32,64}(-0.0)`

Make `Duration::{try_,}from_secs_f{32,64}(-0.0)` return `Duration::ZERO` (as they did before #90247) instead of erroring/panicking.

I'll update this PR to remove the `#![feature(duration_checked_float)]` if #102271 is merged before this PR.

Tracking issue for `try_from_secs_f{32,64}`: #83400
2022-10-14 23:43:46 +02:00
Matthias Krüger
1a5d8a5c59
Rollup merge of #103045 - lukas-code:blank-lines, r=GuillaumeGomez
Remove leading newlines from integer primitive doc examples

fixes https://github.com/rust-lang/rust/issues/103043

```@rustbot``` label +A-docs
2022-10-14 23:43:44 +02:00
bors
bf15a9e526 Auto merge of #101030 - woppopo:const_location, r=scottmcm
Constify `Location` methods

Tracking issue: #102911

Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4789884c2f16ec4fb0e0405d86b794f5
2022-10-14 20:15:51 +00:00
beetrees
c9948f5c5f
Fix Duration::{try_,}from_secs_f{32,64}(-0.0) 2022-10-14 16:07:09 +01:00
Lukas Markeffsky
b8bb40664c remove leading newlines from integer primitive doc examples 2022-10-14 12:14:29 +02:00
Rageking8
7122abaddf more dupe word typos 2022-10-14 12:57:56 +08:00
bors
4891d57f7a Auto merge of #102919 - luojia65:update-stdarch, r=Amanieu
library: update stdarch submodule

It has been one month since we update `stdarch`  submodule into main branch Rust, it includes various fixes in code and more neat documents. This pull request also adds missing features to ensure we can build latest stdarch submodule.

The documents after this pull request:
<details>

![图片](https://user-images.githubusercontent.com/40385009/195123337-a6c4cfaa-a7b9-4574-b524-c43683e6540c.png)
</details>

Comparing to current nightly:
<details>

![图片](https://user-images.githubusercontent.com/40385009/195123430-e047cff1-a925-4d2d-ae1c-da9769383a9c.png)
</details>

r? `@Amanieu`
2022-10-13 12:03:46 +00:00
luojia65
59fea7ecf4 library: update stdarch submodule
add feature target_feature_11 and riscv_target_feature
2022-10-13 09:41:16 +08:00
Pointerbender
ddd119b2fe expand documentation on type conversion w.r.t. UnsafeCell 2022-10-12 23:34:13 +02:00
bors
538f118da1 Auto merge of #102732 - RalfJung:assert_unsafe_precondition2, r=bjorn3
nicer errors from assert_unsafe_precondition

This makes the errors shown by cargo-careful nicer, and since `panic_no_unwind` is `nounwind noreturn` it hopefully doesn't have bad codegen impact. Thanks to `@bjorn3` for the hint!

Would be nice if we could somehow supply our own (static) message to print, currently it always prints `panic in a function that cannot unwind`. But still, this is better than before.
2022-10-12 14:39:43 +00:00
Dylan DPC
d8091f8991
Rollup merge of #102578 - lukas-code:ilog-panic, r=m-ou-se
Panic for invalid arguments of `{integer primitive}::ilog{,2,10}` in all modes

Decision made in https://github.com/rust-lang/rust/issues/100422#issuecomment-1245864700

resolves https://github.com/rust-lang/rust/issues/100422

tracking issue: https://github.com/rust-lang/rust/issues/70887

r? `@m-ou-se`
2022-10-12 11:11:25 +05:30
Ralf Jung
38c78a9ac1 reorder panicking.rs to put main entry points at the top 2022-10-11 22:47:31 +02:00
Ralf Jung
b61e742a39 use panic_fmt_nounwind for assert_unsafe_precondition 2022-10-11 22:47:31 +02:00
Ralf Jung
66282cb47d add panic_fmt_nounwind for panicing without unwinding, and use it for panic_no_unwind 2022-10-11 22:47:31 +02:00
Matthias Krüger
d10b47ef69
Rollup merge of #102445 - jmillikin:cstr-is-empty, r=Mark-Simulacrum
Add `is_empty()` method to `core::ffi::CStr`.

ACP: https://github.com/rust-lang/libs-team/issues/106

Tracking issue: https://github.com/rust-lang/rust/issues/102444
2022-10-11 18:59:48 +02:00
Matthias Krüger
d13f7aef70
Rollup merge of #101774 - Riolku:atomic-update-aba, r=m-ou-se
Warn about safety of `fetch_update`

Specifically as it relates to the ABA problem.

`fetch_update` is a useful function, and one that isn't provided by, say, C++. However, this does not mean the function is magic. It is implemented in terms of `compare_exchange_weak`, and in particular, suffers from the ABA problem. See the following code, which is a naive implementation of `pop` in a lock-free queue:

```rust
fn pop(&self) -> Option<i32> {
    self.front.fetch_update(Ordering::Relaxed, Ordering::Acquire, |front| {
        if front == ptr::null_mut() {
            None
        }
        else {
            Some(unsafe { (*front).next })
        }
    }.ok()
}
```

This code is unsound if called from multiple threads because of the ABA problem. Specifically, suppose nodes are allocated with `Box`. Suppose the following sequence happens:

```
Initial: Queue is X -> Y.

Thread A: Starts popping, is pre-empted.
Thread B: Pops successfully, twice, leaving the queue empty.
Thread C: Pushes, and `Box` returns X (very common for allocators)
Thread A: Wakes up, sees the head is still X, and stores Y as the new head.
```

But `Y` is deallocated. This is undefined behaviour.

Adding a note about this problem to `fetch_update` should hopefully prevent users from being misled, and also, a link to this common problem is, in my opinion, an improvement to our docs on atomics.
2022-10-11 18:59:46 +02:00
Yuki Okushi
ff903bbb71
Rollup merge of #102258 - cjgillot:core-kappa, r=m-ou-se
Remove unused variable in float formatting.
2022-10-11 18:37:52 +09:00
woppopo
a53e3acca9 Change tracking issue from #76156 to #102911 2022-10-11 06:40:37 +00:00
bors
0265a3e93b Auto merge of #96711 - emilio:inline-slice-clone, r=nikic
slice: #[inline] a couple iterator methods.

The one I care about and actually saw in the wild not getting inlined is
clone(). We ended up doing a whole function call for something that just
copies two pointers.

I ended up marking as_slice / as_ref as well because make_slice is
inline(always) itself, and is also the kind of think that can kill
performance in hot loops if you expect it to get inlined. But happy to
undo those.
2022-10-10 12:09:21 +00:00
Dylan DPC
7e16f9f1ea
Rollup merge of #99696 - WaffleLapkin:uplift, r=fee1-dead
Uplift `clippy::for_loops_over_fallibles` lint into rustc

This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.

There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
   ```rust
    for _ in iter.next() {}
    // turns into
    for _ in iter.by_ref() {}
    ```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
   ```rust
   for _ in rx.recv() {}
   // turns into
   while let Some(_) = rx.recv() {}
   ```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
   ```rust
   for _ in f() {}
   // turns into
   for _ in f()? {}
   ```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
   ```rust
   for _ in f() {}
   // turns into
   if let Some(_) = f() {}
   ```
(P.S. `Some` and `Ok` are interchangeable depending on the type)

I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!

Resolves #99272

[`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles
2022-10-10 13:43:40 +05:30
Scott McMurray
0718aeceb3 From<Alignment> for usize & NonZeroUsize 2022-10-09 15:44:49 -07:00
Pointerbender
9c37c801ad expand documentation on type conversion w.r.t. UnsafeCell 2022-10-09 22:32:23 +02:00
Yuki Okushi
38db483af7
Rollup merge of #102072 - scottmcm:ptr-alignment-type, r=thomcc
Add `ptr::Alignment` type

Essentially no new code here, just exposing the previously-`pub(crate)` `ValidAlign` type under the name from the ACP.

ACP: https://github.com/rust-lang/libs-team/issues/108
Tracking Issue: https://github.com/rust-lang/rust/issues/102070

r? ``@ghost``
2022-10-10 00:09:40 +09:00
Maybe Waffle
7434b9f0d1 fixup lint name 2022-10-09 13:07:21 +00:00
Maybe Waffle
75ae20a42f allow for_loop_over_fallibles in a core test 2022-10-09 13:07:20 +00:00
Michael Howell
c58886d428
Rollup merge of #102812 - est31:remove_lazy, r=dtolnay
Remove empty core::lazy and std::lazy

PR #98165 with commits 7c360dc117 and c1a2db3372 has moved all of the components of these modules into different places, namely {std,core}::sync and {std,core}::cell. The empty modules remained. As they are unstable, we can simply remove them.
2022-10-08 18:15:01 -07:00
Matthias Krüger
e6f6ad0576
Rollup merge of #99880 - compiler-errors:escape-ascii-is-not-exact-size-iterator, r=thomcc
`EscapeAscii` is not an `ExactSizeIterator`

Fixes #99878

Do we want/need `EscapeAscii` to be an `ExactSizeIterator`? I guess we could precompute the length of the output if so?
2022-10-08 23:32:02 +02:00
bors
8796e7a9cf Auto merge of #102315 - RalfJung:assert_unsafe_precondition, r=thomcc
add a few more assert_unsafe_precondition

Add debug-assertion checking for `ptr.read()`, `ptr.write(_)`, and `unreachable_unchecked.`

This is quite useful for [cargo-careful](https://github.com/RalfJung/cargo-careful).
2022-10-08 17:59:45 +00:00
est31
4d9d7bf312 Remove empty core::lazy and std::lazy
PR #98165 with commits 7c360dc117 and c1a2db3372
has moved all of the components of these modules into different places,
namely {std,core}::sync and {std,core}::cell. The empty
modules remained. As they are unstable, we can simply remove them.
2022-10-08 15:55:15 +02:00
woppopo
f0b8167a4e Fix test (location_const_file) 2022-10-08 11:48:53 +00:00
bors
8b0c05d9ad Auto merge of #102091 - RalfJung:const_err, r=oli-obk
make const_err a hard error

This lint has been deny-by-default with future incompat wording since [Rust 1.51](https://github.com/rust-lang/rust/pull/80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)

r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/71800
Fixes https://github.com/rust-lang/rust/issues/100114
2022-10-07 20:50:51 +00:00
Dylan DPC
2592609574
Rollup merge of #102300 - scottmcm:simpler-fold-closures, r=Mark-Simulacrum
Use a macro to not have to copy-paste `ConstFnMutClosure::new(&mut fold, NeverShortCircuit::wrap_mut_2_imp)).0` everywhere

Also use that macro to replace a bunch of places that had custom closure-wrappers.

+35 -114 sounds good to me.
2022-10-07 22:05:29 +05:30
Ralf Jung
fd59d44f58 make const_err a hard error 2022-10-07 18:08:49 +02:00
Ralf Jung
6f6433428f add a few more assert_unsafe_precondition 2022-10-07 14:35:12 +02:00
Matthias Krüger
f55fef165e
Rollup merge of #102647 - oli-obk:tilde_const_bounds, r=fee1-dead
Only allow ~const bounds for traits with #[const_trait]

r? `@fee1-dead`
2022-10-04 18:26:39 +02:00
Dylan DPC
c1d4003506
Rollup merge of #101189 - daxpedda:ready-into-inner, r=joshtriplett
Implement `Ready::into_inner()`

Tracking issue: #101196.

This implements a method to unwrap the value inside a `Ready` outside an async context.
See https://docs.rs/futures/0.3.24/futures/future/struct.Ready.html#method.into_inner for previous work.

This was discussed in [Zulip beforehand](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60Ready.3A.3Ainto_inner.28.29.60):
> An example I'm hitting right now:
I have a cross-platform library that provides a functions that returns a `Future`. The only reason why it returns a `Future` is because the WASM platform requires it, but the native doesn't, to make a cross-platform API that is equal for all I just return a `Ready` on the native targets.
>
> Now I would like to expose native-only functions that aren't async, that users can use to avoid having to deal with async when they are targeting native. With `into_inner` that's easily solvable now.
>
> I want to point out that some internal restructuring could be used to solve that problem too, but in this case it's not that simple, the library uses internal traits that return the `Future` already and playing around with that would introduce unnecessary `cfg` in a lot more places. So it is really only a quality-of-life feature.
2022-10-04 16:11:00 +05:30
Oli Scherer
33bcea8f61 Only allow ~const bounds for traits with #[const_trait] 2022-10-04 08:06:54 +00:00
Matthias Krüger
17c65826d3
Rollup merge of #102628 - H4x5:master, r=scottmcm
Change the parameter name of From::from to `value`

The `From` trait is currently defined as:
```rust
pub trait From<T>: Sized {
    fn from(_: T) -> Self;
}
```

The name of the argument is `_`. I am proposing to change it to `value`, ie.
```rust
pub trait From<T>: Sized {
    fn from(value: T) -> Self;
}
```

This would be more consistent with the `TryFrom`, which looks like this:
```rust
pub trait TryFrom<T>: Sized {
    type Error;
    fn try_from(value: T) -> Result<Self, Self::Error>;
}
```

The reason for this proposal is twofold:
1. Consistency with the rest of the standard library. The `TryFrom` trait uses `value`, and no `From` implementation uses the default name (as it is quite useless).
2. When generating trait implementations with rust-analyzer/IntelliJ, the parameter name is copied, and it always has to be changed.

Optionally, another name like `x` could be used. I only propose `value` for consistency with `TryFrom`.

Changing parameter names is not a breaking change.

Note: this was originally posted as an internals thread [here](https://internals.rust-lang.org/t/change-the-argument-name-of-from-from/17480)
2022-10-04 06:14:12 +02:00
bors
1f1defc2f6 Auto merge of #99099 - Stargateur:phantomdata_debug, r=joshtriplett
Add T to PhantomData impl Debug

This add debug information for `PhantomData`, I believe it's make sense to add this to debug impl of `PhantomData` since `T` is what define what is the `PhantomData` just write `"PhantomData"` is not very useful for debugging.

Alternative:

* `PhantomData::<{}>`
* `PhantomData { t: "str_type" }`

`@rustbot` label +T-libs-api -T-libs
2022-10-04 00:56:14 +00:00
bors
f83e0266cf Auto merge of #102632 - matthiaskrgr:rollup-h8s3zmo, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #98218 (Document the conditional existence of `alloc::sync` and `alloc::task`.)
 - #99216 (docs: be less harsh in wording for Vec::from_raw_parts)
 - #99460 (docs: Improve AsRef / AsMut docs on blanket impls)
 - #100470 (Tweak `FpCategory` example order.)
 - #101040 (Fix `#[derive(Default)]` on a generic `#[default]` enum adding unnecessary `Default` bounds)
 - #101308 (introduce `{char, u8}::is_ascii_octdigit`)
 - #102486 (Add diagnostic struct for const eval error in `rustc_middle`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-10-03 20:22:18 +00:00
Matthias Krüger
a5488826a9
Rollup merge of #101308 - nerdypepper:feature/is-ascii-octdigit, r=joshtriplett
introduce `{char, u8}::is_ascii_octdigit`

This feature adds two new APIs: `char::is_ascii_octdigit` and `u8::is_ascii_octdigit`, under the feature gate `is_ascii_octdigit`. These methods are shorthands for `char::is_digit(self, 8)` and `u8::is_digit(self, 8)`:

```rust
// core::char

impl char {
    pub fn is_ascii_octdigit(self) -> bool;
}

// core::num

impl u8 {
    pub fn is_ascii_octdigit(self) -> bool;
}
```

---

Couple of things I need help understanding:

- `const`ness: have I used the right attribute in this case?
- is there a way to run the tests for `core::char` alone, instead of `./x.py test library/core`?
2022-10-03 20:58:56 +02:00