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 3 pull requests #119166

Merged
merged 9 commits into from
Dec 20, 2023
Merged

Rollup of 3 pull requests #119166

merged 9 commits into from
Dec 20, 2023

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GuillaumeGomez and others added 9 commits December 19, 2023 13:39
We have coverage tests that use async functions, but none that use async
blocks.
This reduces the risk of mixing up `fn_source_span` and `body_span`, and makes
it easier to pass along additional fields as needed.
The old code used a heuristic to detect async functions and adjust their
coverage spans to produce better output. But there's no need to resort to a
heuristic when we can just check whether the current function is actually an
`async fn`.
to pick up "[M68k] Fix ODR violation in GISel code (rust-lang#72797)" rust-lang/llvm-project#159
Update documentation for `--env` compilation flag

Part of rust-lang#80792.
As mentioned in rust-lang#118830.

It adds a mention to `tracked_env::var` and also clarifies what triggers a new compilation.

r? `@Nilstrieb`
coverage: Check for `async fn` explicitly, without needing a heuristic

The old code used a heuristic to detect async functions and adjust their coverage spans to produce better output. But there's no need to resort to a heuristic when we can just look back at the original definition and check whether the current function is actually an `async fn`.

In addition to being generally nicer, this also gets rid of the one piece of code that specifically cares about `CoverageSpan::is_closure` representing an actual closure. All remaining code that inspects that field just uses it as an indication that the span is a hole that should be carved out of other spans, and then discarded.

That opens up the possibility of introducing other kinds of “hole” spans, e.g. for nested functions/types/macros, and having them all behave uniformly.

---

`@rustbot` label +A-code-coverage
Update LLVM submodule

to pick up "[M68k] Fix ODR violation in GISel code (rust-lang#72797)" rust-lang/llvm-project#159.

Fixes rust-lang#107668
@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. rollup A PR which is a rollup labels Dec 20, 2023
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=3 rollup=never

@bors
Copy link
Contributor

bors commented Dec 20, 2023

📌 Commit c768419 has been approved by GuillaumeGomez

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 Dec 20, 2023
@bors
Copy link
Contributor

bors commented Dec 20, 2023

⌛ Testing commit c768419 with merge 92ad4b4...

@bors
Copy link
Contributor

bors commented Dec 20, 2023

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing 92ad4b4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 20, 2023
@bors bors merged commit 92ad4b4 into rust-lang:master Dec 20, 2023
12 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Dec 20, 2023
@GuillaumeGomez GuillaumeGomez deleted the rollup-qfgj76w branch December 20, 2023 18:04
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#119115 Update documentation for --env compilation flag 96cac0a434cbd6da796bf34701be4cdacc657117 (link)
#119155 coverage: Check for async fn explicitly, without needing … 595c2220c9c21f875be06f54afdc94ab2c578797 (link)
#119159 Update LLVM submodule 5a0bee31e4b29256a54b0b9c1c0a1cafab731530 (link)

previous master: 8fca8295cb

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

Overall result: ✅ 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
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.1% [-1.1%, -1.1%] 1
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)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.4% [-0.4%, -0.4%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [-0.4%, 0.5%] 2

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
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.7% [-0.8%, -0.6%] 2
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.3%] 1
All ❌✅ (primary) -0.7% [-0.8%, -0.6%] 2

Binary size

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

Bootstrap: 674.047s -> 672.918s (-0.17%)
Artifact size: 312.81 MiB -> 312.81 MiB (0.00%)

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-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants