nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-22 23:04:33 +00:00
Code Issues Packages Projects Releases Wiki Activity
172,693 Commits 7 Branches 139 Tags 1.9 GiB
e2ecb68a0e
Commit Graph

8491 Commits

Author SHA1 Message Date
Dylan DPC
e423a6f5f0
Rollup merge of #99198 - RalfJung:alloc-null-ptr, r=JohnTitor 
add missing null ptr check in alloc example

`alloc` can return null on OOM, if I understood correctly. So we should never just deref a pointer we get from `alloc`.
 2022-07-18 21:14:45 +05:30
Dylan DPC
5ccdf1f6f7
Rollup merge of #98839 - 5225225:assert_transmute_copy_size, r=thomcc 
Add assertion that `transmute_copy`'s U is not larger than T

This is called out as a safety requirement in the docs, but because knowing this can be done at compile time and constant folded (just like the `align_of` branch is removed), we can just panic here.

I've looked at the asm (using `cargo-asm`) of a function that both is correct and incorrect, and the panic is completely removed, or is unconditional, without needing build-std.

I don't expect this to cause much breakage in the wild. I scanned through https://miri.saethlin.dev/ub for issues that would look like this (error: Undefined Behavior: memory access failed: alloc1768 has size 1, so pointer to 8 bytes starting at offset 0 is out-of-bounds), but couldn't find any.

That doesn't rule out it happening in crates tested that fail earlier for some other reason, though, but it indicates that doing this is rare, if it happens at all. A crater run for this would need to be build and test, since this is a runtime thing.

Also added a few more transmute_copy tests.
 2022-07-18 21:14:42 +05:30
bors
9ed0bf9f2b Auto merge of #99223 - saethlin:panicless-split-mut, r=Mark-Simulacrum 
Rearrange slice::split_mut to remove bounds check

Closes https://github.com/rust-lang/rust/issues/86313

Turns out that all we need to do here is reorder the bounds checks to convince LLVM that all the bounds checks can be removed. It seems like LLVM just fails to propagate the original length information past the first bounds check and into the second one. With this implementation it doesn't need to, each check can be proven inbounds based on the one immediately previous.

I've gradually convinced myself that this implementation is unambiguously better based on the above logic, but maybe this is still deserving of a codegen test?

Also the mentioned borrowck limitation no longer seems to exist.
 2022-07-18 10:16:58 +00:00
Yuki Okushi
7c98c92ebc
Rollup merge of #99374 - TethysSvensson:patch-1, r=Dylan-DPC 
Fix doc for `rchunks_exact`

`rchunks_exact` is not a more optimized version of `chunks`, but of `rchunks`.
 2022-07-18 08:40:02 +09:00
Yuki Okushi
796bc7cae3
Rollup merge of #98383 - m-ou-se:remove-memory-order-restrictions, r=joshtriplett 
Remove restrictions on compare-exchange memory ordering.

We currently don't allow the failure memory ordering of compare-exchange operations to be stronger than the success ordering, as was the case in C++11 when its memory model was copied to Rust. However, this restriction was lifted in C++17 as part of [p0418r2](https://wg21.link/p0418r2). It's time  we lift the restriction too.

| Success | Failure | Before | After |
|---------|---------|--------|-------|
| Relaxed | Relaxed | ✔️ | ✔️ |
| Relaxed | Acquire | ❌                | ✔️ |
| Relaxed | SeqCst  | ❌                | ✔️ |
| Acquire | Relaxed | ✔️ | ✔️ |
| Acquire | Acquire | ✔️ | ✔️ |
| Acquire | SeqCst  | ❌                | ✔️ |
| Release | Relaxed | ✔️ | ✔️ |
| Release | Acquire | ❌                | ✔️ |
| Release | SeqCst  | ❌                | ✔️ |
| AcqRel  | Relaxed | ✔️ | ✔️ |
| AcqRel  | Acquire | ✔️ | ✔️ |
| AcqRel  | SeqCst  | ❌                | ✔️ |
| SeqCst  | Relaxed | ✔️ | ✔️ |
| SeqCst  | Acquire | ✔️ | ✔️ |
| SeqCst  | SeqCst  | ✔️ | ✔️ |
| \*      | Release | ❌                | ❌                |
| \*      | AcqRel  | ❌                | ❌                |

Fixes https://github.com/rust-lang/rust/issues/68464
 2022-07-18 08:39:57 +09:00
Tethys Svensson
8c58de5e2c
Fix for rchunks_exact doc 
`rchunks_exact` is not a more optimized version of `chunks`, but of `rchunks`.
 2022-07-17 14:18:36 +02:00
Yuki Okushi
50527690e2
Rollup merge of #99306 - JohnTitor:stabilize-future-poll-fn, r=joshtriplett 
Stabilize `future_poll_fn`

FCP is done: https://github.com/rust-lang/rust/issues/72302#issuecomment-1179620512
Closes #72302

r? `@joshtriplett` as you started FCP

Signed-off-by: Yuki Okushi <jtitor@2k36.org>
 2022-07-17 13:08:52 +09:00
Yuki Okushi
28cce683ad
Rollup merge of #99302 - yaahc:gma-tracking-issue, r=joshtriplett 
add tracking issue to generic member access APIs

Missed as part of https://github.com/rust-lang/rust/pull/98072
 2022-07-17 13:08:51 +09:00
Yuki Okushi
f49d267136
Rollup merge of #99088 - niklasf:stabilize-process_set_process_group, r=joshtriplett 
Document and stabilize process_set_process_group

Tracking issue: https://github.com/rust-lang/rust/issues/93857

FCP finished here: https://github.com/rust-lang/rust/issues/93857#issuecomment-1179551697
 2022-07-17 13:08:50 +09:00
Yuki Okushi
48cf43b752
Rollup merge of #97915 - tbu-:pr_os_string_fmt_write, r=joshtriplett 
Implement `fmt::Write` for `OsString`

This allows to format into an `OsString` without unnecessary
allocations. E.g.

```
let mut temp_filename = path.into_os_string();
write!(&mut temp_filename, ".tmp.{}", process::id());
```
 2022-07-17 13:08:48 +09:00
Yuki Okushi
353d0180bb
Rollup merge of #94927 - c410-f3r:stabilize-let-chains, r=joshtriplett 
Stabilize `let_chains` in Rust 1.64

# Stabilization proposal

This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax.

Tracking issue: #53667
Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22).

## What is stabilized

The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example:

```rust
pub enum Color {
    Blue,
    Red,
    Violet,
}

pub enum Flower {
    Rose,
    Tulip,
    Violet,
}

pub fn roses_are_red_violets_are_blue_printer(
    (first_flower, first_flower_color): (Flower, Color),
    (second_flower, second_flower_color): (Flower, Color),
    pick_up_lines: &[&str],
) {
    if let Flower::Rose = first_flower
        && let Color::Red = first_flower_color
        && let Flower::Violet = second_flower
        && let Color::Blue = second_flower_color
        && let &[first_pick_up_line, ..] = pick_up_lines
    {
        println!("Roses are red, violets are blue, {}", first_pick_up_line);
    }
}

fn main() {
    roses_are_red_violets_are_blue_printer(
        (Flower::Rose, Color::Red),
        (Flower::Violet, Color::Blue),
        &["sugar is sweet and so are you"],
    );
}
```

## Motivation

The main motivation for this feature is improving readability, ergonomics and reducing paper cuts.

For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md).

## What isn't stabilized

* Let chains in match guards (`if_let_guard`)

* Resolution of divergent non-terminal matchers

* The `EXPR is PAT` syntax

## History

* On 2017-12-24, [RFC: if- and while-let-chains](https://github.com/rust-lang/rfcs/pull/2260)
* On 2018-07-12, [eRFC: if- and while-let-chains, take 2](https://github.com/rust-lang/rfcs/pull/2497)
* On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](https://github.com/rust-lang/rust/issues/53667)
* On 2019-03-19, [Run branch cleanup after copy prop](https://github.com/rust-lang/rust/pull/59290)
* On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](https://github.com/rust-lang/rust/pull/59439)
* On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](https://github.com/rust-lang/rust/pull/60225)
* On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](https://github.com/rust-lang/rust/pull/59288)
* On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](https://github.com/rust-lang/rust/pull/60861)
* On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](https://github.com/rust-lang/rust/pull/61988)
* On 2020-11-22, [Reintroduce hir::ExprKind::If](https://github.com/rust-lang/rust/pull/79328)
* On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](https://github.com/rust-lang/rust/pull/80357)
* On 2021-02-19, [Lower condition of if expression before it's "then" block](https://github.com/rust-lang/rust/pull/82308)
* On 2021-09-01, [Fix drop handling for `if let` expressions](https://github.com/rust-lang/rust/pull/88572)
* On 2021-09-04, [Formally implement let chains](https://github.com/rust-lang/rust/pull/88642)
* On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](https://github.com/rust-lang/rust/pull/93086)
* On 2022-01-18, [Introduce `enhanced_binary_op` feature](https://github.com/rust-lang/rust/pull/93049)
* On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](https://github.com/rust-lang/rust/pull/93213)
* On 2022-02-25, [Initiate the inner usage of `let_chains`](https://github.com/rust-lang/rust/pull/94376)
* On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](https://github.com/rust-lang/rust/pull/93437)
* On 2022-02-26, [1 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94396)
* On 2022-02-26, [2 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94400)
* On 2022-02-27, [3 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94420)
* On 2022-02-28, [4 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94445)
* On 2022-02-28, [5 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94448)
* On 2022-02-28, [6 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94465)
* On 2022-03-01, [7 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94476)
* On 2022-03-01, [8 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94484)
* On 2022-03-01, [9 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94498)
* On 2022-03-08, [Warn users about `||` in let chain expressions](https://github.com/rust-lang/rust/pull/94754)

From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled.

## Divergent non-terminal matchers

More specifically, https://github.com/rust-lang/rust/issues/86730.

```rust
macro_rules! mac {
    ($e:expr) => {
        if $e {
            true
        } else {
            false
        }
    };
}

fn main() {
    // OK!
    assert_eq!(mac!(true && let 1 = 1), true);

    // ERROR! Anything starting with `let` is not considered an expression
    assert_eq!(mac!(let 1 = 1 && true), true);
}
```

To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression.

It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers.

## Alternative syntax

Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`.

The introductory snippet would then be written as the following.

```rust
if first_flower is Flower::Rose
    && first_flower_color is Color::Red
    && second_flower is Flower::Violet
    && second_flower_color is Color::Blue
    && pick_up_lines is &[first_pick_up_line, ..]
{
    println!("Roses are red, violets are blue, {}", first_pick_up_line);
}
```

Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse.

## Tests

* [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs)

* [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs)

* [Checks pretty printing output](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs)

* [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs)

* [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs)

* [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs)

* [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs)

* [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime.

* [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs)

* [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs)

* [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs)

Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since https://github.com/rust-lang/rust/pull/80357 and https://github.com/rust-lang/rust/pull/88572. As a result, no bugs were found since the integration of https://github.com/rust-lang/rust/pull/88642.

## Possible future work

* Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`.

* The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in https://github.com/rust-lang/rust/pull/93437.

Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations.

Fixes #53667
 2022-07-17 13:08:47 +09:00
bors
db41351753 Auto merge of #98866 - nagisa:nagisa/align-offset-wroom, r=Mark-Simulacrum 
Add a special case for align_offset /w stride != 1

This generalizes the previous `stride == 1` special case to apply to any
situation where the requested alignment is divisible by the stride. This
in turn allows the test case from #98809 produce ideal assembly, along
the lines of:

    leaq 15(%rdi), %rax
    andq $-16, %rax

This also produces pretty high quality code for situations where the
alignment of the input pointer isn’t known:

    pub unsafe fn ptr_u32(slice: *const u32) -> *const u32 {
        slice.offset(slice.align_offset(16) as isize)
    }

    // =>

    movl %edi, %eax
    andl $3, %eax
    leaq 15(%rdi), %rcx
    andq $-16, %rcx
    subq %rdi, %rcx
    shrq $2, %rcx
    negq %rax
    sbbq %rax, %rax
    orq  %rcx, %rax
    leaq (%rdi,%rax,4), %rax

Here LLVM is smart enough to replace the `usize::MAX` special case with
a branch-less bitwise-OR approach, where the mask is constructed using
the neg and sbb instructions. This appears to work across various
architectures I’ve tried.

This change ends up introducing more branches and code in situations
where there is less knowledge of the arguments. For example when the
requested alignment is entirely unknown. This use-case was never really
a focus of this function, so I’m not particularly worried, especially
since llvm-mca is saying that the new code is still appreciably faster,
despite all the new branching.

Fixes #98809.
Sadly, this does not help with #72356.
 2022-07-16 23:28:28 +00:00
Caio
3266460749 Stabilize let_chains 2022-07-16 20:17:58 -03:00
Simonas Kazlauskas
62a182cf7f Add a special case for align_offset /w stride != 1 
This generalizes the previous `stride == 1` special case to apply to any
situation where the requested alignment is divisible by the stride. This
in turn allows the test case from #98809 produce ideal assembly, along
the lines of:

    leaq 15(%rdi), %rax
    andq $-16, %rax

This also produces pretty high quality code for situations where the
alignment of the input pointer isn’t known:

    pub unsafe fn ptr_u32(slice: *const u32) -> *const u32 {
        slice.offset(slice.align_offset(16) as isize)
    }

    // =>

    movl %edi, %eax
    andl $3, %eax
    leaq 15(%rdi), %rcx
    andq $-16, %rcx
    subq %rdi, %rcx
    shrq $2, %rcx
    negq %rax
    sbbq %rax, %rax
    orq  %rcx, %rax
    leaq (%rdi,%rax,4), %rax

Here LLVM is smart enough to replace the `usize::MAX` special case with
a branch-less bitwise-OR approach, where the mask is constructed using
the neg and sbb instructions. This appears to work across various
architectures I’ve tried.

This change ends up introducing more branches and code in situations
where there is less knowledge of the arguments. For example when the
requested alignment is entirely unknown. This use-case was never really
a focus of this function, so I’m not particularly worried, especially
since llvm-mca is saying that the new code is still appreciably faster,
despite all the new branching.

Fixes #98809.
Sadly, this does not help with #72356.
 2022-07-17 01:27:37 +03:00
Josh Triplett
629b0b488b
Expand documentation for process_group 
Explain PGID 0, and provide the acronym PGID.
 2022-07-16 14:45:16 -07:00
Josh Triplett
3855e86873
Update since version to 1.64 2022-07-16 14:36:48 -07:00
Matthias Krüger
ddc32d1633
Rollup merge of #99317 - yanchith:borrow-vec-ta-as-slice-t, r=Mark-Simulacrum 
Borrow Vec<T, A> as [T]

Hello all,

When `Vec` was parametrized with `A`, the `Borrow` impls were omitted and currently `Vec<T, A>` can't be borrowed as `[T]`. This PR fixes that.

This was probably missed, because the `Borrow` impls are in a different file - `src/alloc/slice.rs`.

We briefly discussed this here: https://github.com/rust-lang/wg-allocators/issues/96 and I was told to go ahead and make a PR :)

I tested this by building the toolchain and building my code that needed the `Borrow` impl against it, but let me know if I should add any tests to this PR.
 2022-07-16 22:30:54 +02:00
Ben Kimock
c9373903e7 Rearrange slice::split_mut to remove bounds check 2022-07-16 12:26:37 -04:00
yanchith
aeb949753e Borrow Vec<T, A> as [T] 2022-07-16 11:58:26 +02:00
Yuki Okushi
083a253e53
Rollup merge of #99277 - joshtriplett:stabilize-core-cstr-alloc-cstring, r=Mark-Simulacrum 
Stabilize `core::ffi::CStr`, `alloc::ffi::CString`, and friends

Stabilize the `core_c_str` and `alloc_c_string` feature gates.

Change `std::ffi` to re-export these types rather than creating type
aliases, since they now have matching stability.
 2022-07-16 17:53:04 +09:00
Yuki Okushi
96474a718b
Rollup merge of #99270 - rhysd:issue-99269, r=Mark-Simulacrum 
Add `#[must_use]` to `Box::from_raw`

Fixes #99269
 2022-07-16 17:53:03 +09:00
Yuki Okushi
8a64529763
Rollup merge of #99264 - eltociear:patch-14, r=compiler-errors 
Fix typo in mod.rs

constuct -> construct
 2022-07-16 17:53:02 +09:00
Yuki Okushi
06eb90ef63
Rollup merge of #98662 - LucasDumont:document_fs_write, r=thomcc 
Add std::fs::write documentation precision

Fixes #97947.

As mentioned in #97947, the documentation is updated
 2022-07-16 17:53:00 +09:00
Yuki Okushi
bf9ed99496
Rollup merge of #98387 - NobodyXu:feature/std_io_Error_try_downgrade_inner, r=yaahc 
Add new unstable API `downcast` to `std::io::Error`

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

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
 2022-07-16 17:52:59 +09:00
Yuki Okushi
084ad59622
Stabilize future_poll_fn 
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
 2022-07-16 10:04:14 +09:00
Jane Losare-Lusby
a9d2ed2ab1 add tracking issue to generic member access APIs 2022-07-15 22:13:43 +00:00
Jane Losare-Lusby
8e8a3be22f
Apply suggestions from code review 2022-07-15 13:17:44 -07:00
Aaron Hill
ef8e322b14
Mark stabilized intrinsics with rustc_allowed_through_unstable_modules 
Fixes #99286

PR #95956 accidentally made these intrinsics unstable when
accessed through the unstable path segment 'std::intrinsics'
 2022-07-15 11:18:40 -05:00
Josh Triplett
d6b7480c2a Stabilize core::ffi::CStr, alloc::ffi::CString, and friends 
Stabilize the `core_c_str` and `alloc_c_string` feature gates.

Change `std::ffi` to re-export these types rather than creating type
aliases, since they now have matching stability.
 2022-07-15 03:10:35 -07:00
rhysd
fa3156ec42 add #[must_use] to Box::from_raw 2022-07-15 17:05:50 +09:00
Dylan DPC
99f3132cd7
Rollup merge of #99113 - WaffleLapkin:arc_simplify, r=Mark-Simulacrum 
Simplify [a]rc code a little

Nothing interesting, just make [a]rc code a little nicer by using `byte_sub` and `let`-`else`.
 2022-07-15 10:39:41 +05:30
Ikko Ashimine
67a6c0a7ee
Fix typo in mod.rs 
constuct -> construct
 2022-07-15 12:57:46 +09:00
Jiahao XU
d8aba1002a
Improve example of downcast 
Co-authored-by: Jane Losare-Lusby <jlusby42@gmail.com>
 2022-07-15 13:04:06 +10:00
bors
74621c764e Auto merge of #99242 - Dylan-DPC:rollup-34bqdh8, r=Dylan-DPC 
Rollup of 6 pull requests

Successful merges:

 - #98072 (Add provider API to error trait)
 - #98580 (Emit warning when named arguments are used positionally in format)
 - #99000 (Move abstract const to middle)
 - #99192 (Fix spans for asm diagnostics)
 - #99222 (Better error message for generic_const_exprs inference failure)
 - #99236 (solaris: unbreak build on native platform)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
 2022-07-14 16:23:07 +00:00
Ralf Jung
080a53a953 add missing null ptr check in alloc example 2022-07-14 11:37:22 -04:00
Dylan DPC
2b17aa67fc
Rollup merge of #98072 - yaahc:generic-member-access, r=thomcc 
Add provider API to error trait

Implements https://github.com/rust-lang/rfcs/pull/2895
 2022-07-14 19:24:02 +05:30
bors
24699bcbad Auto merge of #95956 - yaahc:stable-in-unstable, r=cjgillot 
Support unstable moves via stable in unstable items

part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of https://github.com/rust-lang/rust/pull/90328.

The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge.

This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.
 2022-07-14 13:42:09 +00:00
Dylan DPC
103b8602b7
Rollup merge of #98315 - joshtriplett:stabilize-core-ffi-c, r=Mark-Simulacrum 
Stabilize `core::ffi:c_*` and rexport in `std::ffi`

This only stabilizes the base types, not the non-zero variants, since
those have their own separate tracking issue and have not gone through
FCP to stabilize.
 2022-07-14 14:14:20 +05:30
Josh Triplett
d431338b25 Stabilize core::ffi:c_* and rexport in std::ffi 
This only stabilizes the base types, not the non-zero variants, since
those have their own separate tracking issue and have not gone through
FCP to stabilize.
 2022-07-13 19:28:20 -07:00
Jiahao XU
111253c519
Rename std::io::Error::try_downcast_inner to downcast 
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
 2022-07-14 11:24:44 +10:00
bors
87588a2afd Auto merge of #99136 - CAD97:layout-faster, r=scottmcm 
Take advantage of known-valid-align in layout.rs

An attempt to improve perf by `@nnethercote's` approach suggested in #99117
 2022-07-13 21:01:20 +00:00
Dylan DPC
1e7d04b23b
Rollup merge of #99011 - oli-obk:UnsoundCell, r=eddyb 
`UnsafeCell` blocks niches inside its nested type from being available outside

fixes #87341

This implements the plan by `@eddyb` in https://github.com/rust-lang/rust/issues/87341#issuecomment-886083646

Somewhat related PR (not strictly necessary, but that cleanup made this PR simpler): #94527
 2022-07-13 19:32:34 +05:30
Guillaume Gomez
41eb8ddbf9
Rollup merge of #99148 - SOF3:clarify-xsize-bound, r=scottmcm 
Clarify that [iu]size bounds were only defined for the target arch
 2022-07-13 10:38:45 +02:00
Christopher Durham
11694905b4 Remove duplication of layout size check 2022-07-11 17:58:42 -04:00
Jane Losare-Lusby
655d6e82e3 apply suggestions from code review 2022-07-11 19:18:56 +00:00
bors
7d1f57a757 Auto merge of #97841 - nvzqz:inline-encode-wide, r=thomcc 
Inline Windows `OsStrExt::encode_wide`

User crates currently produce much more code than necessary because the optimizer fails to make assumptions about this method.
 2022-07-11 09:30:54 +00:00
Lucas Dumont
07a0fd2c1e Add std::fs::write documentation precision 
As mentioned in #97947, the documentation is updated
 2022-07-11 09:48:47 +02:00
SOFe
01a9ff0e85
Clarify that [iu]size bounds were only defined for the target arch 2022-07-11 15:08:38 +08:00
Christopher Durham
079d3eb22f Take advantage of known-valid-align in layout.rs 2022-07-10 20:34:39 -04:00
Matthias Krüger
342b666d59
Rollup merge of #99094 - AldaronLau:atomic-ptr-extra-space, r=Dylan-DPC 
Remove extra space in AtomicPtr::new docs
 2022-07-11 00:33:48 +02:00