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 6 pull requests #110994

Merged
merged 16 commits into from
Apr 29, 2023
Merged

Rollup of 6 pull requests #110994

merged 16 commits into from
Apr 29, 2023

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

pietroalbini and others added 16 commits April 21, 2023 15:34
This updates the `openssl-sys` crate to 0.9.87 to support building the
toolchain against the system libraries provided by LibreSSL version 3.7.x.

LibreSSL 3.7.x has been supported since `openssl-sys` version 0.9.85.
In the old setup, if the dereffed-to item has multiple impl blocks,
each one gets its own `div.impl-items` in the section, but there
are no headers separating them. Since the last method in a
`div.impl-items` has no bottom margin, and there are no margins
between these divs, there is no margin between the last method
of one impl and the first method of the following impl.

This patch fixes it by simplifying the HTML. Each Deref block gets
exactly one `div.impl-items`, no matter how many impl blocks it
actually has.
…ectory

This fixes the following recurring error on windows:
```
Traceback (most recent call last):
  File "C:\Users\jyn\src\rust\x.py", line 29, in <module>
    bootstrap.main()
  File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 963, in main
    bootstrap(args)
  File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 927, in bootstrap
    build.download_toolchain()
  File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 437, in download_toolchain
    shutil.rmtree(bin_root)
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 759, in rmtree
    return _rmtree_unsafe(path, onerror)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 617, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 622, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 620, in _rmtree_unsafe
    os.unlink(fullname)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\jyn\\src\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\rust-analyzer-proc-macro-srv.exe'
```
…omez,jyn514,notriddle

rustdoc: Add a new lint for broken inline code

This patch adds `rustdoc::unescaped_backticks`, a new rustdoc lint that will detect broken inline code nodes.

The lint woks by finding stray backticks and with some heuristics tries to guess where the second backtick might be missing.

Here is how it looks:
```rust
#![warn(rustdoc::unescaped_backticks)]

/// `add(a, b) is the same as `add(b, a)`.
pub fn add(a: i32, b: i32) -> i32 { a + b }
```
```text
warning: unescaped backtick
 --> src/lib.rs:3:41
  |
3 | /// `add(a, b) is the same as `add(b, a)`.
  |                                         ^
  |
help: a previous inline code might be longer than expected
  |
3 | /// `add(a, b)` is the same as `add(b, a)`.
  |               +
help: if you meant to use a literal backtick, escape it
  |
3 | /// `add(a, b) is the same as `add(b, a)\`.
  |                                         +
```

If we can't get proper spans, for example if the doc comment comes from a macro expansion, we print the suggestion in help messages instead. Here's a [real-world example](https://docs.rs/tracing-subscriber/0.3.17/tracing_subscriber/layer/trait.Filter.html#method.max_level_hint):

```text
warning: unescaped backtick
    --> /tracing-subscriber-0.3.17/src/layer/mod.rs:1400:9
     |
1400 | /         /// Returns an optional hint of the highest [verbosity level][level] that
1401 | |         /// this `Filter` will enable.
1402 | |         ///
1403 | |         /// If this method returns a [`LevelFilter`], it will be used as a hint to
...    |
1427 | |         /// [`Interest`]: tracing_core::subscriber::Interest
1428 | |         /// [rebuild]: tracing_core::callsite::rebuild_interest_cache
     | |_____________________________________________________________________^
     |
     = help: a previous inline code might be longer than expected
              change: Therefore, if the `Filter will change the value returned by this
             to this: Therefore, if the `Filter` will change the value returned by this
     = help: if you meant to use a literal backtick, escape it
              change: [`rebuild_interest_cache`][rebuild] is called after the value of the max
             to this: [`rebuild_interest_cache\`][rebuild] is called after the value of the max
```

You can find more examples [here](https://gist.github.com/lukas-code/7678ddf5c608aee97b3a669de80d3465).

A limitation of the current implementation is, that it cannot suggest removing misplaced backticks, for example [here](https://docs.rs/tikv-jemalloc-sys/0.5.3+5.3.0-patched/tikv_jemalloc_sys/fn.mallctl.html).

The lint is allowed by default ~~and nightly-only~~ for now, ~~but without a feature gate. This is similar to how `rustdoc::invalid_html_tags` and `rustdoc::bare_urls` were handled.~~
…sts, r=Mark-Simulacrum

Update tests for libtest `--format json`

This PR makes the test work on beta and stable, and adds a test ensuring the option is not available on beta and stable. Backported these commits from rust-lang#110414.
… r=Nilstrieb

Deny the `unsafe_op_in_unsafe_fn` lint in `rustc_arena`.

r? ```@Nilstrieb```
…crum

Add support for LibreSSL 3.7.x

This updates the `openssl-sys` crate to 0.9.87 to support building the toolchain against the system libraries provided by LibreSSL version 3.7.x.

LibreSSL 3.7.x has been supported since `openssl-sys` version 0.9.85.
…GuillaumeGomez

rustdoc: fix weird margins between Deref impl items

## Before

![image](https://user-images.githubusercontent.com/1593513/235245977-90770591-22c1-4a27-9464-248a3729a2b7.png)

## After

![image](https://user-images.githubusercontent.com/1593513/235246009-0e83113e-42b7-4e29-981d-969f9d20af01.png)

## Description

In the old setup, if the dereffed-to item has multiple impl blocks, each one gets its own `div.impl-items` in the section, but there are no headers separating them. Since the last method in a `div.impl-items` has no bottom margin, and there are no margins between these divs, there is no margin between the last method of one impl and the first method of the following impl.

This patch fixes it by simplifying the HTML. Each Deref block gets exactly one `div.impl-items`, no matter how many impl blocks it actually has.
windows: kill rust-analyzer-proc-macro-srv before deleting stage0 directory

This fixes the following recurring error on windows:
```
Traceback (most recent call last):
  File "C:\Users\jyn\src\rust\x.py", line 29, in <module>
    bootstrap.main()
  File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 963, in main
    bootstrap(args)
  File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 927, in bootstrap
    build.download_toolchain()
  File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 437, in download_toolchain
    shutil.rmtree(bin_root)
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 759, in rmtree
    return _rmtree_unsafe(path, onerror)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 617, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 622, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 620, in _rmtree_unsafe
    os.unlink(fullname)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\jyn\\src\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\rust-analyzer-proc-macro-srv.exe'
```

Fixes rust-lang#107018.

r? ```@ChrisDenton```
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 29, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Apr 29, 2023

📌 Commit 72de69e 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 29, 2023
@bors
Copy link
Contributor

bors commented Apr 29, 2023

⌛ Testing commit 72de69e with merge eb62877...

@bors
Copy link
Contributor

bors commented Apr 29, 2023

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

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

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#110979 3e0cc5bcf6121760f47c594aca70c3ec1e2545b2
#110964 6286f8cc9c52163b657e1b69654a977820c0705d
#110951 9e0392acbe6e81b31752f43a1642cf6ba6c49101
#110950 7486958dd5f92ce941443ccbb5ecab20ce75d27a
#110644 906e6b4d378ac4f78b77917a9e26bab694688563
#105848 98ec0fd306a73081bdcdbef97e31cc21d1f5ed16

previous master: 27d22d2045

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 (eb62877): comparison URL.

Overall result: ❌✅ regressions and improvements - 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)
0.5% [0.4%, 0.7%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.3% [-0.3%, -0.3%] 2
All ❌✅ (primary) 0.5% [0.4%, 0.7%] 3

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

Cycles

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

@rustbot rustbot added the perf-regression Performance regression. label Apr 29, 2023
@lqd
Copy link
Member

lqd commented May 2, 2023

The regressions are pretty small and only on doc benchmarks. The run-time detailed query on clap has run_lints as a possible source and markdown parsing shows up in cachegrind, so it seems likely to be related to #105848.

It does seem expected, a new lint is running and it takes some time when there's a lot of docs. I've checked with GuillaumeGomez that this was not cause for concern, and they agreed.

(The externs improvements here look like noise though.)

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label May 2, 2023
@matthiaskrgr matthiaskrgr deleted the rollup-wv4u5yi branch March 16, 2024 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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-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.