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 #118473

Merged
merged 13 commits into from
Nov 30, 2023
Merged

Rollup of 5 pull requests #118473

merged 13 commits into from
Nov 30, 2023

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

notriddle and others added 13 commits November 29, 2023 11:02
This restriction made sense back when spaces separated function
parameters, but now that they separate path components, there's
no real ambiguity any more.

Additionally, the Rust language allows it.
This is already covered by the normal unexpected char path.
This way, most of the parsing code doesn't need to be designed to handle
it, since they should always be treated exactly the same anyhow.
When trying to create an inaccessible ADT due to private fields, handle
the case when no fields were passed.

```
error: cannot construct `Foo` with struct literal syntax due to private fields
  --> $DIR/issue-76077.rs:8:5
   |
LL |     foo::Foo {};
   |     ^^^^^^^^
   |
   = note: private field `you_cant_use_this_field` that was not provided
```
There's no such thing as a big section header, so I don't know why the
name was used.
If the TargetMachine is disposed after the Context is disposed, it can
lead to use after frees in some cases.

I've observed this happening occasionally on code compiled for
aarch64-pc-windows-msvc using `-Zstack-protector=strong` but other users
have reported AVs from host aarch64-pc-windows-msvc compilers as well.
…aumeGomez,jsha

rustdoc-search: allow spaces around `::` in path query

This restriction made sense back when spaces separated function parameters, but now that they separate path components, there's no real ambiguity any more.

Additionally, the Rust language allows it.

The other two commits are misc code cleanup.
…rrors

Tweak message on ADT with private fields building

When trying to create an inaccessible ADT due to private fields, handle the case when no fields were passed.

```
error: cannot construct `Foo` with struct literal syntax due to private fields
  --> $DIR/issue-76077.rs:8:5
   |
LL |     foo::Foo {};
   |     ^^^^^^^^
   |
   = note: private field `you_cant_use_this_field` that was not provided
```
…ffleLapkin

rustc_span: Remove unused symbols.

As noted  here, there is no guarantee that all pre-interned symbols are used.

https://github.com/rust-lang/rust/blob/b10cfcd65fd7f7b1ab9beb34798b2108de003452/compiler/rustc_span/src/symbol.rs#L124-L125

This was done starting with using ripgrep to search for `sym::whatever`. I removed anything that didn't show up. However this had a huge number of false positives, due to extensive macro use. Then there was a manual phase of adding back all the ones used my macros.

I don't think this was worth my time to do, but it's done now . ¯\_(ツ)_/¯
…header, r=GuillaumeGomez

rustdoc: remove small from  `small-section-header`

There's no such thing as a big section header, so I don't know why the name was used.
…r=Nilstrieb

Dispose llvm::TargetMachines prior to llvm::Context being disposed

If the TargetMachine is disposed after the Context is disposed, it can lead to use after frees in some cases.

I've observed this happening occasionally on code compiled for aarch64-pc-windows-msvc using `-Zstack-protector=strong` but other users have reported AVs from host aarch64-pc-windows-msvc compilers as well.

I was not able to extract a self-contained test case yet so there is no accompanying test.

Fixes rust-lang#118462
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler 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 Nov 30, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Nov 30, 2023

📌 Commit 640a431 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 Nov 30, 2023
@bors
Copy link
Contributor

bors commented Nov 30, 2023

⌛ Testing commit 640a431 with merge 1670ff6...

@bors
Copy link
Contributor

bors commented Nov 30, 2023

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 1670ff6 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 30, 2023
@bors bors merged commit 1670ff6 into rust-lang:master Nov 30, 2023
12 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Nov 30, 2023
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#118452 rustdoc-search: allow spaces around :: in path query 4bf0530bb906f30cd2f8dbf5a81232bfc8350d0a (link)
#118453 Tweak message on ADT with private fields building 3063e572c63783da069c983a95df9c8722bb0db6 (link)
#118456 rustc_span: Remove unused symbols. 33805cb429e7f527a688d9b27933b7b7a98ec8de (link)
#118458 rustdoc: remove small from small-section-header 0a10f2fe28ef9162c7c7e86872699cc7edd8b064 (link)
#118464 Dispose llvm::TargetMachines prior to llvm::Context being d… ef7a2827dbdadf00dfe8f13294612d7c42e3cdae (link)

previous master: c52b8763bf

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

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1670ff6): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)
1.4% [1.4%, 1.4%] 1
Regressions ❌
(secondary)
0.1% [0.1%, 0.1%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.4% [1.4%, 1.4%] 1

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)
1.5% [1.5%, 1.5%] 1
Regressions ❌
(secondary)
5.6% [5.6%, 5.6%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.5% [-6.7%, -1.2%] 8
All ❌✅ (primary) 1.5% [1.5%, 1.5%] 1

Cycles

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

Binary size

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

Bootstrap: 672.84s -> 671.792s (-0.16%)
Artifact size: 313.38 MiB -> 313.36 MiB (-0.01%)

@rustbot rustbot added the perf-regression Performance regression. label Nov 30, 2023
@matthiaskrgr matthiaskrgr deleted the rollup-q96bm3u 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. perf-regression Performance regression. 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-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.

8 participants