nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-23 15:23:46 +00:00
Code Issues Packages Projects Releases Wiki Activity
209,184 Commits 7 Branches 139 Tags 1.9 GiB
3ad4d24751
Commit Graph

4136 Commits

Author SHA1 Message Date
Neutron3529
3ad4d24751
Optimize the code to run faster. 
such code is copy from
https://github.com/rust-lang/rust/blob/master/library/std/src/f32.rs
and
https://github.com/rust-lang/rust/blob/master/library/std/src/f64.rs
using r+rhs.abs() is faster than calc it directly.
Bench result:
```
$ cargo bench
   Compiling div-euclid v0.1.0 (/me/div-euclid)
    Finished bench [optimized] target(s) in 1.01s
     Running unittests src/lib.rs (target/release/deps/div_euclid-7a4530ca7817d1ef)

running 7 tests
test tests::it_works ... ignored
test tests::bench_aaabs     ... bench:  10,498,793 ns/iter (+/- 104,360)
test tests::bench_aadefault ... bench:  11,061,862 ns/iter (+/- 94,107)
test tests::bench_abs       ... bench:  10,477,193 ns/iter (+/- 81,942)
test tests::bench_default   ... bench:  10,622,983 ns/iter (+/- 25,119)
test tests::bench_zzabs     ... bench:  10,481,971 ns/iter (+/- 43,787)
test tests::bench_zzdefault ... bench:  11,074,976 ns/iter (+/- 29,633)

test result: ok. 0 passed; 0 failed; 1 ignored; 6 measured; 0 filtered out; finished in 19.35s
```
bench code:
```
#![feature(test)]
extern crate test;

fn rem_euclid(a:i32,rhs:i32)->i32{
    let r = a % rhs;
    if r < 0 { r + rhs.abs() } else { r }
}

#[cfg(test)]
mod tests {
    use super::*;
    use test::Bencher;
    use rand::prelude::*;
    use rand::rngs::SmallRng;
    const N:i32=1000;
    #[test]
    fn it_works() {
        let a: i32 = 7; // or any other integer type
        let b = 4;

        let d:Vec<i32>=(-N..=N).collect();
        let n:Vec<i32>=(-N..0).chain(1..=N).collect();

        for i in &d {
            for j in &n {
                assert_eq!(i.rem_euclid(*j),rem_euclid(*i,*j));
            }
        }

        assert_eq!(rem_euclid(a,b), 3);
        assert_eq!(rem_euclid(-a,b), 1);
        assert_eq!(rem_euclid(a,-b), 3);
        assert_eq!(rem_euclid(-a,-b), 1);
    }


    #[bench]
    fn bench_aaabs(b: &mut Bencher) {
        let mut d:Vec<i32>=(-N..=N).collect();
        let mut n:Vec<i32>=(-N..0).chain(1..=N).collect();
        let mut rng=SmallRng::from_seed([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,21]);
        n.shuffle(&mut rng);
        d.shuffle(&mut rng);
        n.shuffle(&mut rng);
        b.iter(||{
            let mut res=0;
            for i in &d {
                for j in &n {
                    res+=rem_euclid(*i,*j);
                }
            }
            res
        });
    }
    #[bench]
    fn bench_aadefault(b: &mut Bencher) {
        let mut d:Vec<i32>=(-N..=N).collect();
        let mut n:Vec<i32>=(-N..0).chain(1..=N).collect();
        let mut rng=SmallRng::from_seed([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,21]);
        n.shuffle(&mut rng);
        d.shuffle(&mut rng);
        n.shuffle(&mut rng);
        b.iter(||{
            let mut res=0;
            for i in &d {
                for j in &n {
                    res+=i.rem_euclid(*j);
                }
            }
            res
        });
    }

    #[bench]
    fn bench_abs(b: &mut Bencher) {
        let d:Vec<i32>=(-N..=N).collect();
        let n:Vec<i32>=(-N..0).chain(1..=N).collect();
        b.iter(||{
            let mut res=0;
            for i in &d {
                for j in &n {
                    res+=rem_euclid(*i,*j);
                }
            }
            res
        });
    }
    #[bench]
    fn bench_default(b: &mut Bencher) {
        let d:Vec<i32>=(-N..=N).collect();
        let n:Vec<i32>=(-N..0).chain(1..=N).collect();
        b.iter(||{
            let mut res=0;
            for i in &d {
                for j in &n {
                    res+=i.rem_euclid(*j);
                }
            }
            res
        });
    }

    #[bench]
    fn bench_zzabs(b: &mut Bencher) {
        let mut d:Vec<i32>=(-N..=N).collect();
        let mut n:Vec<i32>=(-N..0).chain(1..=N).collect();
        let mut rng=SmallRng::from_seed([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,21]);
        d.shuffle(&mut rng);
        n.shuffle(&mut rng);
        d.shuffle(&mut rng);
        b.iter(||{
            let mut res=0;
            for i in &d {
                for j in &n {
                    res+=rem_euclid(*i,*j);
                }
            }
            res
        });
    }
    #[bench]
    fn bench_zzdefault(b: &mut Bencher) {
        let mut d:Vec<i32>=(-N..=N).collect();
        let mut n:Vec<i32>=(-N..0).chain(1..=N).collect();
        let mut rng=SmallRng::from_seed([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,21]);
        d.shuffle(&mut rng);
        n.shuffle(&mut rng);
        d.shuffle(&mut rng);
        b.iter(||{
            let mut res=0;
            for i in &d {
                for j in &n {
                    res+=i.rem_euclid(*j);
                }
            }
            res
        });
    }
}
```
 2022-11-03 16:35:37 +08:00
Dylan DPC
bbd3a10663
Rollup merge of #103774 - compiler-errors:dyn-trait-in-type-name, r=eholk 
Format `dyn Trait` better in `type_name` intrinsic

Noticed this in #103764 (though not related to that PR at all!)

```rust
trait Foo {
    type Bar;
}

fn main() {
    println!(
        "`dyn Fn(i32, i32) -> i32` => `{}`",
        std::any::type_name::<dyn Fn(i32, i32) -> i32>()
    );
    println!(
        "`dyn Foo<Bar = i32> + Send + Sync` => `{}`",
        std::any::type_name::<dyn Foo<Bar = i32> + Send + Sync>()
    );
}
```

```
`dyn Fn(i32, i32) -> i32` => `dyn core::ops::function::Fn<(i32, i32)>+Output = i32`
`dyn Foo<Bar = i32> + Send + Sync` => `dyn playground::Foo+Bar = i32+core::marker::Sync+core::marker::Send`
```

Just reuse `pretty_print_dyn_existential` which already makes an attempt to make its output stable.
 2022-11-02 22:32:03 +05:30
Manish Goregaokar
d4bd794f5e
Rollup merge of #103084 - inquisitivecrystal:control-flow, r=scottmcm 
Derive `Eq` and `Hash` for `ControlFlow`

There's really no reason for `ControlFlow` not to derive these traits. This is the part of #96416 that no one objected to, but that PR seems stale. The `Eq` derive was also [requested](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60ControlFlow.3A.20Eq.60/near/303610659) by `@lcnr` on Zulip to allow for pattern matching.

This change requires an FCP because it's insta-stable.

Closes #96416.
 2022-11-01 20:00:37 -04:00
Michael Goulet
e24df2778f Format dyn Trait better in type_name intrinsic 2022-11-01 20:41:47 +00:00
Dylan DPC
20528baac4
Rollup merge of #103729 - RalfJung:align-of-val-packed, r=oli-obk 
interpret: fix align_of_val on packed types

Fixes https://github.com/rust-lang/miri/issues/2632

r? `@oli-obk`
 2022-11-01 14:12:26 +05:30
Amanieu d'Antras
56074b5231 Rewrite implementation of #[alloc_error_handler] 
The new implementation doesn't use weak lang items and instead changes
`#[alloc_error_handler]` to an attribute macro just like
`#[global_allocator]`.

The attribute will generate the `__rg_oom` function which is called by
the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom`
function is defined in any crate then the compiler shim will call
`__rdl_oom` in the alloc crate which will simply panic.

This also fixes link errors with `-C link-dead-code` with
`default_alloc_error_handler`: `__rg_oom` was previously defined in the
alloc crate and would attempt to reference the `oom` lang item, even if
it didn't exist. This worked as long as `__rg_oom` was excluded from
linking since it was not called.

This is a prerequisite for the stabilization of
`default_alloc_error_handler` (#102318).
 2022-10-31 16:32:57 +00:00
Dylan DPC
d80bcf8316
Rollup merge of #103766 - lukas-code:error-in-core, r=Dylan-DPC 
Add tracking issue to `error_in_core`

This was merged in https://github.com/rust-lang/rust/pull/99917 without a tracking issue, so I'm creating one now: https://github.com/rust-lang/rust/issues/103765
 2022-10-31 14:52:57 +05:30
Lukas Markeffsky
f56d3c3140 Add tracking issue to error_in_core 2022-10-30 17:26:46 +01:00
Matthias Krüger
e4821d743b
Rollup merge of #103715 - tshepang:consistency, r=Dylan-DPC 
use consistent terminology

I did not see other traits using the "interface" word
 2022-10-30 00:09:25 +02:00
Matthias Krüger
22e320b2c9
Rollup merge of #100006 - jyn514:update-copy, r=dtolnay 
Make `core::mem::copy` const

cc https://github.com/rust-lang/rust/issues/98262, https://github.com/rust-lang/libs-team/issues/78
 2022-10-30 00:09:23 +02:00
Ralf Jung
d366471e58 interpret: fix align_of_val on packed types 2022-10-29 15:58:32 +02:00
Tshepang Mbambo
a36a37e5a8 use consistent terminology 
I did not see other traits using the "interface" word
 2022-10-29 09:23:12 +02:00
Matthias Krüger
b3ca68f9e9
Rollup merge of #102961 - reitermarkus:const-cstr-from-ptr, r=oli-obk 
Make `CStr::from_ptr` `const`.

Should be included in https://github.com/rust-lang/rust/issues/101719.

cc ``@WaffleLapkin``
 2022-10-29 08:57:34 +02:00
bors
7174231ae6 Auto merge of #102737 - RalfJung:poll_fn_pin, r=Mark-Simulacrum 
poll_fn and Unpin: fix pinning

See [IRLO](https://internals.rust-lang.org/t/surprising-soundness-trouble-around-pollfn/17484) for details: currently `poll_fn` is very subtle to use, since it does not pin the closure, so creating a `Pin::get_unchcked(&mut capture)` inside the closure is unsound. This leads to actual miscompilations with `futures::join!`.

IMO the proper fix is to pin the closure when the future is pinned, which is achieved by changing the `Unpin` implementation. This is a breaking change though. 1.64.0 was *just* released, so maybe this is still okay?

The alternative would be to add some strong comments to the docs saying that closure captures are *not pinned* and doing `Pin::get_unchecked` on them is unsound.
 2022-10-28 23:27:33 +00:00
Markus Reiter
b3f9277a17
Remove unneeded attribute. 2022-10-28 14:17:34 +02:00
Matthias Krüger
c75e6f559f
Rollup merge of #103394 - Pointerbender:unsafecell-docs, r=Amanieu 
Clarify documentation about the memory layout of `UnsafeCell`

This PR addresses a [comment](https://github.com/rust-lang/rust/pull/101717#issuecomment-1279908390) by `@RalfJung` in PR #101717 to further clarify the documentation of `UnsafeCell<T>`. The previous PR was merged already before we had a chance to correct this, hence this second PR :)

To goal of this PR is:

1. Split the paragraph about the memory layout of `UnsafeCell<T>` and the usage of `UnsafeCell::(raw_)get()` into two paragraphs, so that it is easier to digest for the reader.
2. Slightly simplify the previously added examples in order to reduce redundancy between the new examples and the examples that already [existed](ddd119b2fe/library/core/src/cell.rs (L1858-L1908)) before these 2 PRs (which remained untouched by both PRs).
 2022-10-27 15:03:56 +02:00
Matthias Krüger
6d43dfb7bb
Rollup merge of #103110 - RalfJung:manual-send, r=thomcc 
remove redundant Send impl for references

Also explain why the other instance is not redundant, move it next to the trait they are implementing, and out of the redundant module. This seems to go back all the way to 35ca50bd56, not sure why the module was added.

The instance for `&mut` is the default instance we get anyway, and we don't have anything similar for `Sync`, so IMO we should be consistent and not have the redundant instance here, either.
 2022-10-27 15:03:55 +02:00
Matthias Krüger
0cd87148d9
Rollup merge of #103106 - saethlin:from_exposed_docs, r=thomcc 
Try to say that memory outside the AM is always exposed

cc ``@Gankra`` ``@thomcc``

I want to confidently tell people that they can use `from_exposed_addr` to get a pointer for doing MMIO and/or other hardware interactions done with volatile reads/writes at particular addresses outside the Rust AM. Currently, the docs indicate that would be UB.

With this change, now the docs indicate that this is intended to be a valid use of `from_exposed_addr`.

r? ``@RalfJung``
 2022-10-27 09:25:09 +02:00
Matthias Krüger
2937621aa7
Rollup merge of #103035 - saethlin:assert_unsafe_precondition3, r=thomcc 
Even nicer errors from assert_unsafe_precondition

For example, now running `cargo test` with this patch I get things like:
```
$ cargo +stage1 test
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests src/lib.rs (target/debug/deps/malloc_buf-9d105ddf86862995)

running 5 tests
thread 'tests::test_null_buf' panicked at 'unsafe precondition violated: is_aligned_and_not_null(data) &&
    crate::mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize', /home/ben/rust/library/core/src/slice/raw.rs:93:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread panicked while panicking. aborting.
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `/tmp/malloc_buf-1.0.0/target/debug/deps/malloc_buf-9d105ddf86862995` (signal: 6, SIGABRT: process abort signal)
```

This is still not perfect, but these are better for another PR:
* `stringify!` is trying to do clever pretty-printing on the `expr` inside `assert_unsafe_precondition` and can even add a newline.
* It would be nice to print a bit more information about where the problem is. Perhaps this is `cfg_attr(debug_assertions, track_caller)`, or perhaps it the function name added to `Location`.

cc ``@RalfJung`` this is what I was thinking of for https://github.com/rust-lang/rust/pull/102732#discussion_r989068907
 2022-10-27 09:25:08 +02:00
Pointerbender
166d8b8c2b add "Memory layout" subsection to documentation of UnsafeCell for additional clarity 2022-10-27 06:32:36 +02:00
Ben Kimock
458aaa5a23 Print the precondition we violated, and visible through output capture 
Co-authored-by: Ralf Jung <post@ralfj.de>
 2022-10-26 22:09:17 -04:00
Yuki Okushi
77145c042d
Rollup merge of #103580 - lukas-code:guaranteed_ne, r=GuillaumeGomez 
Fix typo in docs for `guaranteed_ne`

`==` -> `!=`
 2022-10-27 08:30:58 +09:00
Yuki Okushi
26ad51ff87
Rollup merge of #103567 - RalfJung:ptr-eq-dyn-trait, r=dtolnay 
ptr::eq: clarify that comparing dyn Trait is fragile

Also remove the dyn trait example from `ptr::eq` since those tests are not actually guaranteed to pass due to how unstable vtable comparison is.

Cc ``@rust-lang/libs-api``
Cc discussion following https://github.com/rust-lang/rust/pull/80505
 2022-10-27 08:30:57 +09:00
Lukas Markeffsky
cce46e9ae2 Fix typo in docs for guaranteed_ne 2022-10-26 16:50:08 +02:00
Ben Kimock
bd947632b5
Update library/core/src/ptr/mod.rs 
Co-authored-by: Ralf Jung <post@ralfj.de>
 2022-10-26 07:14:20 -07:00
Ralf Jung
1946a1842e explicitly mention that both components of wide prts are compared 2022-10-26 14:20:31 +02:00
Ralf Jung
99a74afa5f ptr::eq: clarify that comparing dyn Trait is fragile 2022-10-26 11:15:14 +02:00
Dylan DPC
8ed3a80b9a
Rollup merge of #103287 - saethlin:faster-len-check, r=thomcc 
Use a faster allocation size check in slice::from_raw_parts

I've been perusing through the codegen changes that result from turning on the standard library debug assertions. The previous check in here uses saturating arithmetic, which in my experience sometimes makes LLVM just fail to optimize things around the saturating operation.

Here is a demo of the codegen difference: https://godbolt.org/z/WMEqrjajW
Before:
```asm
example::len_check_old:
        mov     rax, rdi
        mov     ecx, 3
        mul     rcx
        setno   cl
        test    rax, rax
        setns   al
        and     al, cl
        ret

example::len_check_old:
        mov     rax, rdi
        mov     ecx, 8
        mul     rcx
        setno   cl
        test    rax, rax
        setns   al
        and     al, cl
        ret
```
After:
```asm
example::len_check_new:
        movabs  rax, 3074457345618258603
        cmp     rdi, rax
        setb    al
        ret

example::len_check_new:
        shr     rdi, 60
        sete    al
        ret
```

Running rustc-perf locally, this looks like up to a 4.5% improvement when `debug-assertions-std = true`.

Thanks ```@LegionMammal978``` (I think that's you?) for turning my idea into a much cleaner implementation.

r? ```@thomcc```
 2022-10-26 11:29:53 +05:30
Ben Kimock
0c3ae7d97c Try to say that memory outside the AM is always exposed 
Co-authored-by: Ralf Jung <post@ralfj.de>
 2022-10-25 17:58:29 -04:00
Dylan DPC
d2d44f619f
Rollup merge of #98204 - Kixiron:stable-unzip, r=thomcc 
Stabilize `Option::unzip()`

Stabilizes `Option::unzip()`, closes #87800

```@rustbot``` modify labels: +T-libs-api
 2022-10-25 14:43:13 +05:30
Yuki Okushi
c1f9d985d7
Rollup merge of #102271 - lopopolo:lopopolo/stabilize-duration-try-from-secs-float, r=dtolnay 
Stabilize `duration_checked_float`

## Stabilization Report

This stabilization report is for a stabilization of `duration_checked_float`, tracking issue: https://github.com/rust-lang/rust/issues/83400.

### Implementation History

- https://github.com/rust-lang/rust/pull/82179
- https://github.com/rust-lang/rust/pull/90247
- https://github.com/rust-lang/rust/pull/96051
- Changed error type to `FromFloatSecsError` in https://github.com/rust-lang/rust/pull/90247
- https://github.com/rust-lang/rust/pull/96051 changes the rounding mode to round-to-nearest instead of truncate.

## API Summary

This stabilization report proposes the following API to be stabilized in `core`, along with their re-exports in `std`:

```rust
// core::time

impl Duration {
    pub const fn try_from_secs_f32(secs: f32) -> Result<Duration, TryFromFloatSecsError>;
    pub const fn try_from_secs_f64(secs: f64) -> Result<Duration, TryFromFloatSecsError>;
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct TryFromFloatSecsError { ... }

impl core::fmt::Display for TryFromFloatSecsError { ... }
impl core::error::Error for TryFromFloatSecsError { ... }
```

These functions are made const unstable under `duration_consts_float`, tracking issue #72440.

There is an open question in the tracking issue around what the error type should be called which I was hoping to resolve in the context of an FCP.

In this stabilization PR, I have altered the name of the error type to `TryFromFloatSecsError`. In my opinion, the error type shares the name of the method (adjusted to accommodate both types of floats), which is consistent with other error types in `core`, `alloc` and `std` like `TryReserveError` and `TryFromIntError`.

## Experience Report

Code such as this is ready to be converted to a checked API to ensure it is panic free:

```rust
impl Time {
    pub fn checked_add_f64(&self, seconds: f64) -> Result<Self, TimeError> {
        // Fail safely during `f64` conversion to duration
        if seconds.is_nan() || seconds.is_infinite() {
            return Err(TzOutOfRangeError::new().into());
        }

        if seconds.is_sign_positive() {
            self.checked_add(Duration::from_secs_f64(seconds))
        } else {
            self.checked_sub(Duration::from_secs_f64(-seconds))
        }
    }
}
```

See: https://github.com/artichoke/artichoke/issues/2194.

`@rustbot` label +T-libs-api -T-libs

cc `@mbartlett21`
 2022-10-24 19:32:26 +09:00
bors
56f132565e Auto merge of #100848 - xfix:use-metadata-for-slice-len, r=thomcc 
Use ptr::metadata in <[T]>::len implementation

This avoids duplication of ptr::metadata code.

I believe this is acceptable as the previous approach essentially duplicated `ptr::metadata` because back then `rustc_allow_const_fn_unstable` annotation did not exist.

I would like somebody to ping `@rust-lang/wg-const-eval` as the documentation says:

> Always ping `@rust-lang/wg-const-eval` if you are adding more rustc_allow_const_fn_unstable attributes to any const fn.
 2022-10-24 04:14:46 +00:00
Pointerbender
5673536153
fix typos 
Co-authored-by: Ralf Jung <post@ralfj.de>
 2022-10-24 04:27:37 +02:00
Michael Howell
ae2b1f096f
Rollup merge of #103447 - ajtribick:maybe_uninit_doc_update, r=scottmcm 
`MaybeUninit`: use `assume_init_drop()` in the partially initialized array example

The `assume_init_drop()` method does the same thing as the pointer conversion, and makes the example more straightforward.
 2022-10-23 14:48:19 -07:00
Michael Howell
acc269d65b
Rollup merge of #100462 - zohnannor:master, r=thomcc 
Clarify `array::from_fn` documentation

I've seen quite a few of people on social media confused of where the length of array is coming from in the newly stabilized `array::from_fn` example.

This PR tries to clarify the documentation on this.
 2022-10-23 14:48:13 -07:00
Andrew Tribick
560433ac86 MaybeUninit: use assume_init_drop() in the partially initialized array example 2022-10-23 19:09:18 +02:00
Dylan DPC
b22559f547
Rollup merge of #103346 - HeroicKatora:metadata_of_const_pointer_argument, r=dtolnay 
Adjust argument type for mutable with_metadata_of (#75091)

The method takes two pointer arguments: one `self` supplying the pointer value, and a second pointer supplying the metadata.

The new parameter type more clearly reflects the actual requirements. The provenance of the metadata parameter is disregarded completely. Using a mutable pointer in the call site can be coerced to a const pointer while the reverse is not true.

In some cases, the current parameter type can thus lead to a very slightly confusing additional cast. [Example](cad93775eb).

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```

This could then instead be simplified to:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = uninit.as_ptr().with_metadata_of(&**val);
```

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

``@dtolnay`` you're reviewed #95249, would you mind chiming in?
 2022-10-22 16:28:09 +05:30
Dylan DPC
3f49f9506f
Rollup merge of #103329 - saethlin:nonnull-precondition, r=thomcc 
Add a forgotten check for NonNull::new_unchecked's precondition

Looks like I forgot this function a while ago in https://github.com/rust-lang/rust/pull/92686

r? ```@thomcc```
 2022-10-22 16:28:08 +05:30
bors
5c8bff74bc Auto merge of #101263 - lopopolo:lopopolo/c-unwind-fn-ptr-impls, r=thomcc 
Add default trait implementations for "c-unwind" ABI function pointers

Following up on #92964, only add default trait implementations for the `c-unwind` family of function pointers. The previous attempt in #92964 added trait implementations for many more ABIs and ran into concerns regarding the increase in size of the libcore rlib.

An attempt to abstract away function pointer types behind a unified trait to reduce the duplication of trait impls is being discussed in #99531 but this change looks to be blocked on a lang MCP.

Following `@RalfJung's` suggestion in https://github.com/rust-lang/rust/pull/99531#issuecomment-1233440142, this commit is another cut at #92964 but it _only_ adds the impls for `extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.

I am interested in landing this patch to unblock the stabilization of the `c_unwind` feature.

RFC: https://github.com/rust-lang/rfcs/pull/2945
Tracking Issue: https://github.com/rust-lang/rust/issues/74990
 2022-10-21 20:59:03 +00:00
Andreas Molzer
71c39dea4d Argument type for mutable with_metadata_of (#75091) 
The method takes two pointer arguments: one `self` supplying the pointer
value, and a second pointer supplying the metadata.

The new parameter type more clearly reflects the actual requirements.
The provenance of the metadata parameter is disregarded completely.
Using a mutable pointer in the call site can be coerced to a const
pointer while the reverse is not true.

An example of the current use:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```

This could then instead be simplified to:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = uninit.as_ptr().with_metadata_of(&**val);
```
 2022-10-21 14:46:14 +02:00
Ben Kimock
9b6791078a Add a missing precondition check 2022-10-20 20:40:35 -04:00
Matthias Krüger
cfb424a044
Rollup merge of #103281 - thomcc:long-overdue, r=jyn514 
Adjust `transmute{,_copy}` to be clearer about which of `T` and `U` is input vs output

This is essentially a documentation-only change (although it does touch code in an irrelevant way).
 2022-10-20 22:42:39 +02:00
Ryan Lopopolo
efe61dab21
Skip C-unwind fn pointer impls with the bootstrap compiler 
These need to wait until #103239 makes it into the bootstrap compiler.
 2022-10-20 07:37:17 -07:00
Pointerbender
16104474ad clarify documentation about the memory layout of UnsafeCell 2022-10-20 08:37:47 +02:00
Thom Chiovoloni
afd08175de
Adjust transmute{,_copy} to be clearer about which of T and U is input vs output 2022-10-19 22:36:14 -07:00
Ben Kimock
cfcb0a2135 Use a faster allocation size check in slice::from_raw_parts 2022-10-20 00:30:00 -04:00
Ryan Lopopolo
531679684c
Update stability annotations on fnptr impls for C-unwind ABI 2022-10-19 19:17:32 -07:00
Ryan Lopopolo
16dd5737b0
Add default trait implementations for "c-unwind" ABI function pointers 
Following up on #92964, only add default trait implementations for the
`c-unwind` family of function pointers. The previous attempt in #92964
added trait implementations for many more ABIs and ran into concerns
regarding the increase in size of the libcore rlib.

An attempt to abstract away function pointer types behind a unified
trait to reduce the duplication of trait impls is being discussed in #99531
but this change looks to be blocked on a lang MCP.

Following @RalfJung's suggestion in
https://github.com/rust-lang/rust/pull/99531#issuecomment-1233440142,
this commit is another cut at #92964 but it _only_ adds the impls for
`extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.

I am interested in landing this patch to unblock the stabilization of
the `c_unwind` feature.

RFC: https://github.com/rust-lang/rfcs/pull/2945
Tracking Issue: https://github.com/rust-lang/rust/issues/74990
 2022-10-19 19:17:32 -07:00
clubby789
19bc8fb05a Remove extra spaces 2022-10-19 23:54:00 +01:00
inquisitivecrystal
4a92cf6156 Derive Eq and Hash for ControlFlow 2022-10-19 13:25:34 -07:00