Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 6 pull requests #103105

Merged
merged 16 commits into from
Oct 16, 2022
Merged

Rollup of 6 pull requests #103105

merged 16 commits into from
Oct 16, 2022

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Pointerbender and others added 16 commits September 12, 2022 11:12
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
…yout, 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>`.
…r=scottmcm

Add MaybeUninit array transpose From impls

See discussion in rust-lang#101179 and rust-lang#96097. I believe this solution offers the simplest implementation with minimal future API regret.

`@RalfJung` mind doing a correctness review?
Update pkg-config

I'd like to be able to cross-compile rustc in a scenario where it'd be really helpful to have rust-lang/pkg-config-rs@cd3ccca.  I've done some test builds of the compiler on x86_64 linux, targeting x86_64 linux and aarch64 linux.
…imes, r=cjgillot

pretty: fix to print some lifetimes on HIR pretty-print

HIR pretty-printer doesn't seem to print some lifetimes in types. This PR fixes that.

Closes rust-lang#85089
Surround type with backticks

Very smol PR. :)
…r=notriddle

Fix settings page

Thanks to rust-lang#103060, I discovered that the settings page was badly rendered. This PR fixes it.

Before:
![Screenshot from 2022-10-15 16-02-41](https://user-images.githubusercontent.com/3050060/195990668-42e0b16b-3146-4864-b822-6f6a80fb77a5.png)

After:
![Screenshot from 2022-10-15 16-02-31](https://user-images.githubusercontent.com/3050060/195990664-20f967df-8989-4336-bca9-be52baab8e81.png)

r? ```@notriddle```
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 16, 2022
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Oct 16, 2022

📌 Commit 66a2bba has been approved by JohnTitor

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 16, 2022
@bors
Copy link
Contributor

bors commented Oct 16, 2022

⌛ Testing commit 66a2bba with merge e928a46...

@bors
Copy link
Contributor

bors commented Oct 16, 2022

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing e928a46 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 16, 2022
@bors bors merged commit e928a46 into rust-lang:master Oct 16, 2022
@rustbot rustbot added this to the 1.66.0 milestone Oct 16, 2022
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#103088 78e801e700f634b1a281c9259dc62cc71cac476d
#103082 5c8877d6b4d6b28081865bf70186ce8cd01c5007
#103080 428328f55021185e42e5b0fa86388ac2deef82d2
#103033 33c0e60c3b5b9776752fecd70deb9d9bdf977472
#102023 22dd75861719ed26b6a3a4bd75b87fdb3e877748
#101717 3c75839bda062583e2b7b02546983fcc483ff05a

previous master: 75dbd5b8c3

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@JohnTitor JohnTitor deleted the rollup-x4ivrix branch October 16, 2022 07:49
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (e928a46): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
8.1% [8.1%, 8.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.7% [-3.6%, -2.2%] 3
Improvements ✅
(secondary)
-5.3% [-5.5%, -5.0%] 2
All ❌✅ (primary) -2.7% [-3.6%, -2.2%] 3

Footnotes

  1. the arithmetic mean of the percent change 2

  2. number of relevant changes 2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants