-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 7 pull requests #102915
Rollup of 7 pull requests #102915
Conversation
Before the documentation sometimes referred to an "rwlock" and sometimes to "`RwLock`".
When this was added, the sidebar had a bit more complex style. It can be removed, now.
Remove unused variable in float formatting.
Consistently write `RwLock` Before the documentation sometimes referred to an "rwlock" and sometimes to "`RwLock`".
Never panic in `thread::park` and `thread::park_timeout` fixes rust-lang#102398 `@rustbot` label +T-libs +T-libs-api
…r=m-ou-se scoped threads: pass closure through MaybeUninit to avoid invalid dangling references The `main` function defined here looks roughly like this, if it were written as a more explicit stand-alone function: ```rust // Not showing all the `'lifetime` tracking, the point is that // this closure might live shorter than `thread`. fn thread(control: ..., closure: impl FnOnce() + 'lifetime) { closure(); control.signal_done(); // A lot of time can pass here. } ``` Note that `thread` continues to run even after `signal_done`! Now consider what happens if the `closure` captures a reference of lifetime `'lifetime`: - The type of `closure` is a struct (the implicit unnameable closure type) with a `&'lifetime mut T` field. References passed to a function are marked with `dereferenceable`, which is LLVM speak for *this reference will remain live for the entire duration of this function*. - The closure runs, `signal_done` runs. Then -- potentially -- this thread gets scheduled away and the main thread runs, seeing the signal and returning to the user. Now `'lifetime` ends and the memory the reference points to might be deallocated. - Now we have UB! The reference that as passed to `thread` with the promise of remaining live for the entire duration of the function, actually got deallocated while the function still runs. Oops. Long-term I think we should be able to use `ManuallyDrop` to fix this without `unsafe`, or maybe a new `MaybeDangling` type. I am working on an RFC for that. But in the mean time it'd be nice to fix this so that Miri with `-Zmiri-retag-fields` (which is needed for "full enforcement" of all the LLVM flags we generate) stops erroring on scoped threads. Fixes rust-lang#101983 r? `@m-ou-se`
…, r=m-ou-se fix backtrace small typo
Move lifetime resolution module to rustc_hir_analysis. Now that lifetime resolution has been removed from it, this file has nothing to do in `rustc_resolve`. It's purpose is to compute Debruijn indices for lifetimes, so let's put it in type collection.
… r=GuillaumeGomez rustdoc: remove unneeded `<div>` wrapper from sidebar DOM When this was added, the sidebar had a bit more complex style. It can be removed, now. Preview: https://notriddle.com/notriddle-rustdoc-demos/sidebar-block/std/index.html
@bors r+ p=7 rollup=never |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 1e926f0652 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (bb93450): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Footnotes |
@rust-timer build f574c8fbc90567e0e8a24441750c84a7ce98c81f |
Queued f574c8fbc90567e0e8a24441750c84a7ce98c81f with parent 1e926f0, future comparison URL. |
Finished benchmarking commit (f574c8fbc90567e0e8a24441750c84a7ce98c81f): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Footnotes |
Hmm.... the other PRs in this roll up are either rustdoc changes, library changes (to threading libs), or docs changes so not sure which to test next. Even more curious is that running callgrind-diff for two test cases, the biggest diff in calls is in |
|
Successful merges:
RwLock
#102277 (Consistently writeRwLock
)thread::park
andthread::park_timeout
#102412 (Never panic inthread::park
andthread::park_timeout
)<div>
wrapper from sidebar DOM #102898 (rustdoc: remove unneeded<div>
wrapper from sidebar DOM)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup