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 5 pull requests #97729

Merged
merged 12 commits into from
Jun 4, 2022
Merged

Rollup of 5 pull requests #97729

merged 12 commits into from
Jun 4, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

thomcc and others added 12 commits May 27, 2022 22:12
Avoid zero-sized allocs in ThinBox if T and H are both ZSTs.

This was surprisingly tricky, and took longer to get right than expected. `ThinBox` is a surprisingly subtle piece of code. That said, in the end, a lot of this was due to overthinking[^overthink] -- ultimately the fix ended up fairly clean and simple.

[^overthink]: Honestly, for a while I was convinced this couldn't be done without allocations or runtime branches in these cases, but that's obviously untrue.

Anyway, as a result of spending all that time debugging, I've extended the tests quite a bit, and also added more debug assertions. Many of these helped for subtle bugs I made in the middle (for example, the alloc/drop tracking is because I ended up double-dropping the value in the case where both were ZSTs), they're arguably a bit of overkill at this point, although I imagine they could help in the future too.

Anyway, these tests cover a wide range of size/align cases, nd fully pass under miri[^1]. They also do some smoke-check asserting that the value has the correct alignment, although in practice it's totally within the compiler's rights to delete these assertions since we'd have already done UB if they get hit. They have more boilerplate than they really need, but it's not *too* bad on a per-test basis.

A notable absence from testing is atypical header types, but at the moment it's impossible to manually implement `Pointee`. It would be really nice to have testing here, since it's not 100% obvious to me that the aligned read/write we use for `H` are correct in the face of arbitrary combinations of `size_of::<H>()`, `align_of::<H>()`, and `align_of::<T>()`. (That said, I spent a while thinking through it and am *pretty* sure it's fine -- I'd just feel... better if we could test some cases for non-ZST headers which have unequal and align).

[^1]: Or at least, they pass under miri if I copy the code and tests into a new crate and run miri on it (after making it less stdlibified).

Fixes rust-lang#96485.

I'd request review ``@yaahc,`` but I believe you're taking some time away from reviews, so I'll request from the previous PR's reviewer (I think that the context helps, even if the actual change didn't end up being bad here).

r? ``@joshtriplett``
Lazily allocate and initialize pthread locks.

Lazily allocate and initialize pthread locks.

This allows {Mutex, Condvar, RwLock}::new() to be const, while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS, we cannot directly use the (private) APIs that pthread's locks are implemented with, making it impossible for us to use anything other than pthread while still preserving priority inheritance, etc.

This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP.

Tracking issue: rust-lang#93740
…g, r=wesleywiser

Support the `#[expect]` attribute on fn parameters (RFC-2383)

A small PR to allow the `#[expect]` attribute on function parameters.

Nothing more to say, I hope everyone reading this has a lovely day.

---

r? ``@wesleywiser``

closes: rust-lang#97650

cc: rust-lang#85549
…eywiser

Fix reachability analysis for const methods

Use `method_might_be_inlined` directly for `ImplItemKind::Fn` instead of duplicating the logic in `def_id_represents_local_inlined_item`.

This is parallel to how we use `item_might_be_inlined` for `ItemKind::Fn` in that same body.

Fixes rust-lang#97708
…rror-spans, r=Dylan-DPC

Tighten spans for bad fields in struct deriving `Copy`

r? `@estebank`

Closes rust-lang#89137 for good, I think

Not sure if this is what you were looking for in rust-lang#89137 (comment)
@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. rollup A PR which is a rollup labels Jun 4, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jun 4, 2022

📌 Commit 8c4c698 has been approved by Dylan-DPC

@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 Jun 4, 2022
@bors
Copy link
Contributor

bors commented Jun 4, 2022

⌛ Testing commit 8c4c698 with merge c7b0452...

@bors
Copy link
Contributor

bors commented Jun 4, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing c7b0452 to master...

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (c7b0452): comparison url.

Instruction count

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

Max RSS (memory usage)

Results
  • Primary benchmarks: mixed results
  • Secondary benchmarks: 🎉 relevant improvements found
mean1 max count2
Regressions 😿
(primary)
1.3% 1.3% 1
Regressions 😿
(secondary)
N/A N/A 0
Improvements 🎉
(primary)
-1.7% -3.4% 2
Improvements 🎉
(secondary)
-3.1% -4.1% 3
All 😿🎉 (primary) -0.7% -3.4% 3

Cycles

Results
  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 🎉 relevant improvement found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
N/A N/A 0
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
-2.4% -2.4% 1
All 😿🎉 (primary) N/A N/A 0

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants