Skip to content

Rollup of 8 pull requests - #110252

Merged
bors merged 21 commits into
rust-lang:masterfrom
matthiaskrgr:rollup-ovaixra
Apr 13, 2023
Merged

Rollup of 8 pull requests#110252
bors merged 21 commits into
rust-lang:masterfrom
matthiaskrgr:rollup-ovaixra

Conversation

@matthiaskrgr

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Ezrashawand others added 21 commits April 7, 2023 14:32
Receiver disconnection relies on the incorrect assumption that
`head.index != tail.index` implies that the channel is initialized (i.e
`head.block` and `tail.block` point to allocated blocks). However, it
can happen that `head.index != tail.index` and `head.block == null` at
the same time which leads to a segfault when a channel is dropped in
that state.
This can happen because initialization is performed in two steps. First,
the tail block is allocated and the `tail.block` is set. If that is
successful `head.block` is set to the same pointer. Importantly,
initialization is skipped if `tail.block` is not null.
Therefore we can have the following situation:
1. Thread A starts to send the first value of the channel, observes that
`tail.block` is null and begins initialization. It sets `tail.block`
to point to a newly allocated block and then gets preempted.
`head.block` is still null at this point.
2. Thread B starts to send the second value of the channel, observes
that `tail.block` *is not* null and proceeds with writing its value
in the allocated tail block and sets `tail.index` to 1.
3. Thread B drops the receiver of the channel which observes that
`head.index != tail.index` (0 and 1 respectively), therefore there
must be messages to drop. It starts traversing the linked list from
`head.block` which is still a null pointer, leading to a segfault.
This PR fixes this problem by waiting for initialization to complete
when `head.index != tail.index` and the `head.block` is still null. A
similar check exists in `start_recv` for similar reasons.
Fixesrust-lang#110001
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
… literals"
Reverts PR rust-lang#108031
Fixes (doesnt close until beta backported) rust-lang#109746
This reverts commit e3f9db5.
This reverts commit 98b82ae.
This reverts commit 380fa26.
Before, rustdoc was missing `-C passes=list` and the "Available options"
header.
Making these match allows testing that they match exactly.
This make rustdoc resilient to changes in the debugging options while
still testing that it matches rustc.
Replace rustdoc-ui/{c,z}-help tests with a stable run-make test
This make rustdoc resilient to changes in the debugging options while still testing that it matches rustc.
Fixesrust-lang#109391.
…on-code, r=davidtwco
fix: ensure bad `#[test]` invocs retain correct AST
Fixesrust-lang#109816
Ensures that a `StmtKind::Item` doesn't get converted into a plain `Item` (causing the ICE from the linked issue) Also unifies the error path a bit.
sync::mpsc: synchronize receiver disconnect with initialization
Receiver disconnection relies on the incorrect assumption that `head.index != tail.index` implies that the channel is initialized (i.e `head.block` and `tail.block` point to allocated blocks). However, it can happen that `head.index != tail.index` and `head.block == null` at the same time which leads to a segfault when a channel is dropped in that state.
This can happen because initialization is performed in two steps. First, the tail block is allocated and the `tail.block` is set. If that is successful `head.block` is set to the same pointer. Importantly, initialization is skipped if `tail.block` is not null.
Therefore we can have the following situation:
1. Thread A starts to send the first value of the channel, observes that `tail.block` is null and begins initialization. It sets `tail.block` to point to a newly allocated block and then gets preempted. `head.block` is still null at this point.
2. Thread B starts to send the second value of the channel, observes that `tail.block` *is not* null and proceeds with writing its value in the allocated tail block and sets `tail.index` to 1.
3. Thread B drops the receiver of the channel which observes that `head.index != tail.index` (0 and 1 respectively), therefore there must be messages to drop. It starts traversing the linked list from `head.block` which is still a null pointer, leading to a segfault.
This PR fixes this problem by waiting for initialization to complete when `head.index != tail.index` and the `head.block` is still null. A similar check exists in `start_recv` for similar reasons.
Fixesrust-lang#110001
…ws, r=lcnr
Report overflows gracefully with new solver
avoid reporting overflows as ambiguity errors, so that the error message is clearer.
r? ```@lcnr```
Fix x check --stage 1 when download-ci-llvm=false
Bootstrap tries to avoid building LLVM unless it needs to; in particular we only build it for `x build`, not `x check`. Unfortunately, the check forgot about existence of stages - it would break if you used `x check --stage 1`:
```
= note: /usr/bin/ld: cannot find -lPolly: No such file or directory
/usr/bin/ld: cannot find -lPollyISL: No such file or directory
```
Fix it to work for stage 1.
I recommend reading this commit-by-commit; the first one makes a bunch of whitespace changes but otherwise doesn't change the logic.
…trochenkov
Do not use ImplDerivedObligationCause for inherent impl method error reporting
We were constructing a `TraitRef` out of impl substs, for an *inherent* impl that has no corresponding trait. Instead of doing that, let's construct a meaningful obligation cause code, and instead adjust the error reporting machinery to handle that correctly.
Fixesrust-lang#110131
cc rust-lang#106702, which introduced this regression
…avidtwco
Revert "Don't recover lifetimes/labels containing emojis as character literals"
Reverts PR rust-lang#108031 per rust-lang#109754 (comment)
Fixes (doesnt close until beta backported) rust-lang#109746
This reverts commit e3f9db5.
This reverts commit 98b82ae.
This reverts commit 380fa26.
…otriddle
Fix `--extend-css` option
Fixesrust-lang#110002.
The file was generated in the wrong folder so I moved it into `static.files` as it made more sense to have there instead of changing the path in the templates.
I also added a GUI test to ensure that this option won't break unexpectedly again.
@rustbotrustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Apr 12, 2023
@matthiaskrgr

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=8

@bors

bors commented Apr 12, 2023

Copy link
Copy Markdown
Collaborator

📌 Commit b01f0d3 has been approved by matthiaskrgr

It is now in the queue for this repository.

@borsbors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 12, 2023
@bors

bors commented Apr 12, 2023

Copy link
Copy Markdown
Collaborator

⌛ Testing commit b01f0d3 with merge 9693b17...

@bors

bors commented Apr 13, 2023

Copy link
Copy Markdown
Collaborator

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 9693b17 to master...

@borsbors added the merged-by-bors This PR was explicitly merged by bors. label Apr 13, 2023
@bors
bors merged commit 9693b17 into rust-lang:masterApr 13, 2023
@rustbotrustbot added this to the 1.70.0 milestone Apr 13, 2023
@rust-timer

Copy link
Copy Markdown
Collaborator

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (9693b17): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

meanrangecount
Regressions ❌
(primary)
--0
Regressions ❌
(secondary)
0.2%[0.2%, 0.3%]2
Improvements ✅
(primary)
--0
Improvements ✅
(secondary)
-1.1%[-1.3%, -0.9%]2
All ❌✅ (primary)--0

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.

meanrangecount
Regressions ❌
(primary)
3.5%[3.5%, 3.5%]1
Regressions ❌
(secondary)
2.7%[2.7%, 2.7%]1
Improvements ✅
(primary)
-0.6%[-1.1%, -0.4%]4
Improvements ✅
(secondary)
-1.8%[-1.8%, -1.8%]1
All ❌✅ (primary)0.2%[-1.1%, 3.5%]5

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.

meanrangecount
Regressions ❌
(primary)
0.5%[0.5%, 0.5%]1
Regressions ❌
(secondary)
--0
Improvements ✅
(primary)
-0.4%[-0.4%, -0.4%]1
Improvements ✅
(secondary)
-2.2%[-2.3%, -2.1%]2
All ❌✅ (primary)0.0%[-0.4%, 0.5%]2

@matthiaskrgr
matthiaskrgr deleted the rollup-ovaixra branch March 16, 2024 18:19
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-borsThis PR was explicitly merged by bors.rollupA PR which is a rollupS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.WG-trait-system-refactorThe Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@matthiaskrgr@bors@rust-timer@rustbot@Ezrashaw@petrosagg@jyn514@compiler-errors@GuillaumeGomez