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 8 pull requests #110252

Merged
merged 21 commits into from
Apr 13, 2023
Merged

Rollup of 8 pull requests #110252

merged 21 commits into from
Apr 13, 2023

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Ezrashaw and 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.

Fixes rust-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.

Fixes rust-lang#109391.
…on-code, r=davidtwco

fix: ensure bad `#[test]` invocs retain correct AST

Fixes rust-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.

Fixes rust-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.

Fixes rust-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

Fixes rust-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.
@rustbot rustbot 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 rollup A PR which is a rollup labels Apr 12, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Apr 12, 2023

📌 Commit b01f0d3 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors 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
Copy link
Contributor

bors commented Apr 12, 2023

⌛ Testing commit b01f0d3 with merge 9693b17...

@bors
Copy link
Contributor

bors commented Apr 13, 2023

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 13, 2023
@bors bors merged commit 9693b17 into rust-lang:master Apr 13, 2023
@rustbot rustbot added this to the 1.70.0 milestone Apr 13, 2023
@rust-timer
Copy link
Collaborator

@rust-timer
Copy link
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.

mean range count
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.

mean range count
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.

mean range count
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 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-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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants