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 7 pull requests #125331

Merged
merged 26 commits into from
May 20, 2024
Merged

Rollup of 7 pull requests #125331

merged 26 commits into from
May 20, 2024

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

cardigan1008 and others added 26 commits May 9, 2024 14:36
Fix rust-lang#124819, where a if-less block causes a wrong output. It is
caused by get_return_block in get_fn_decl. In get_return_block,
when a else-less if expression is the tail expression, the check
for next_node will keep iterating. So it is necessary to make a
early return in the check.
This currently has no effect, but is expected to be useful when expanding
support for branch coverage and MC/DC coverage.
Some of these cases currently don't occur in practice, but are included for
completeness, and to avoid having to add them later as branch coverage and
MC/DC coverage start building more complex expressions.
…d lifetimes

```
error: lifetime may not live long enough
  --> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5
   |
LL | fn foo(mut x: Ref, y: Ref) {
   |        -----       - has type `Ref<'_, '1>`
   |        |
   |        has type `Ref<'_, '2>`
LL |     x.b = y.b;
   |     ^^^^^^^^^ assignment requires that `'1` must outlive `'2`
   |
help: consider introducing a named lifetime parameter
   |
LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) {
   |       ++++           ++++++++        ++++++++
```

As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following

```
help: consider introducing a named lifetime parameter
   |
LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) {
   |       ++++           ++++++++        ++++++++
```

but I believe this to still be an improvement over the status quo.

CC rust-lang#40990.
```
error: lifetime may not live long enough
 --> f205.rs:8:16
  |
7 |     fn resolve_symbolic_reference(&self, reference: Option<Reference>) -> Option<Reference> {
  |                                   -      --------- has type `Option<Reference<'1>>`
  |                                   |
  |                                   let's call the lifetime of this reference `'2`
8 |         return reference;
  |                ^^^^^^^^^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
  |
help: consider introducing a named lifetime parameter
  |
7 |     fn resolve_symbolic_reference<'a>(&'a self, reference: Option<Reference<'a>>) -> Option<Reference<'a>> {
  |                                  ++++  ++                                  ++++                      ++++
```

The correct suggestion would be

```
help: consider introducing a named lifetime parameter
  |
7 |     fn resolve_symbolic_reference<'a>(&self, reference: Option<Reference<'a>>) -> Option<Reference<'a>> {
  |                                  ++++                                   ++++                      ++++
```

but we are not doing the analysis to detect that yet. If we constrain `&'a self`, then the return type with a borrow will implicitly take its lifetime from `'a`, it is better to make it explicit in the suggestion, in case that `&self` *doesn't* need to be `'a`, but the return does.
… `run-rustfix`

```
error: lifetime may not live long enough
  --> $DIR/lt-ref-self.rs:12:9
   |
LL |     fn ref_self(&self, f: &u32) -> &u32 {
   |                 -         - let's call the lifetime of this reference `'1`
   |                 |
   |                 let's call the lifetime of this reference `'2`
LL |         f
   |         ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
   |
help: consider introducing a named lifetime parameter and update trait if needed
   |
LL |     fn ref_self<'b>(&'b self, f: &'b u32) -> &'b u32 {
   |                ++++  ++           ++          ++
```
…ceiver

Do not suggest constraining the `&self` param, but rather the return type.
If that is wrong (because it is not sufficient), a follow up error will tell the
user to fix it. This way we lower the chances of *over* constraining, but still
get the cake of "correctly" contrained in two steps.

This is a correct suggestion:

```
error: lifetime may not live long enough
  --> $DIR/ex3-both-anon-regions-return-type-is-anon.rs:9:9
   |
LL |     fn foo<'a>(&self, x: &i32) -> &i32 {
   |                -         - let's call the lifetime of this reference `'1`
   |                |
   |                let's call the lifetime of this reference `'2`
LL |         x
   |         ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
   |
help: consider introducing a named lifetime parameter and update trait if needed
   |
LL |     fn foo<'a>(&self, x: &'a i32) -> &'a i32 {
   |                           ++          ++
```

While this is incomplete because it should suggestino `&'a self`

```
error: lifetime may not live long enough
  --> $DIR/ex3-both-anon-regions-self-is-anon.rs:7:19
   |
LL |     fn foo<'a>(&self, x: &Foo) -> &Foo {
   |                -         - let's call the lifetime of this reference `'1`
   |                |
   |                let's call the lifetime of this reference `'2`
LL |         if true { x } else { self }
   |                   ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
   |
help: consider introducing a named lifetime parameter and update trait if needed
   |
LL |     fn foo<'a>(&self, x: &'a Foo) -> &'a Foo {
   |                           ++          ++
```

but the follow up error is

```
error: lifetime may not live long enough
 --> tests/ui/lifetimes/lifetime-errors/ex3-both-anon-regions-self-is-anon.rs:7:30
  |
6 |     fn foo<'a>(&self, x: &'a Foo) -> &'a Foo {
  |            --  - let's call the lifetime of this reference `'1`
  |            |
  |            lifetime `'a` defined here
7 |         if true { x } else { self }
  |                              ^^^^ method was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1`
  |
help: consider introducing a named lifetime parameter and update trait if needed
  |
6 |     fn foo<'a>(&'a self, x: &'a Foo) -> &'a Foo {
  |                 ++
```
Suggest setting lifetime in borrowck error involving types with elided lifetimes

```
error: lifetime may not live long enough
  --> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5
   |
LL | fn foo(mut x: Ref, y: Ref) {
   |        -----       - has type `Ref<'_, '1>`
   |        |
   |        has type `Ref<'_, '2>`
LL |     x.b = y.b;
   |     ^^^^^^^^^ assignment requires that `'1` must outlive `'2`
   |
help: consider introducing a named lifetime parameter
   |
LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) {
   |       ++++           ++++++++        ++++++++
```

As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following

```
help: consider introducing a named lifetime parameter
   |
LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) {
   |       ++++           ++++++++        ++++++++
```

but I believe this to still be an improvement over the status quo.

Fix rust-lang#40990.
Check whether the next_node is else-less if in get_return_block

Fix rust-lang#124819
coverage: Memoize and simplify counter expressions

When creating coverage counter expressions as part of coverage instrumentation, we often end up creating obviously-redundant expressions like `c1 + (c0 - c1)`, which is equivalent to just `c0`.

To avoid doing so, this PR checks when we would create an expression matching one of 5 patterns, and uses the simplified form instead:
- `(a - b) + b` → `a`.
- `(a + b) - b` → `a`.
- `(a + b) - a` → `b`.
- `a + (b - a)` → `b`.
- `a - (a - b)` → `b`.

Of all the different ways to combine 3 operands and 2 operators, these are the patterns that allow simplification.

(Some of those patterns currently don't occur in practice, but are included anyway for completeness, to avoid having to add them later as branch coverage and MC/DC coverage support expands.)

---

This PR also adds memoization for newly-created (or newly-simplified) counter expressions, to avoid creating duplicates.

This currently makes no difference to the final mappings, but is expected to be useful for MC/DC coverage of match expressions, as proposed by rust-lang#124278 (comment).
…e8472

add some codegen tests for issue 120493

I forgot to add these in rust-lang#123878.
…eature-gate, r=pnkfelix

 Add an experimental feature gate for global registration

See rust-lang#125119 for the tracking issue.
…mples-whitespaces, r=jieyouxu

Migrate `run-make/rustdoc-scrape-examples-whitespace` to `rmake.rs`

Part of rust-lang#121876.

r? `@jieyouxu`
@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. labels May 20, 2024
@rustbot rustbot added the rollup A PR which is a rollup label May 20, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented May 20, 2024

📌 Commit 1640225 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 May 20, 2024
@bors
Copy link
Contributor

bors commented May 20, 2024

⌛ Testing commit 1640225 with merge be71fd4...

@bors
Copy link
Contributor

bors commented May 20, 2024

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 20, 2024
@bors bors merged commit be71fd4 into rust-lang:master May 20, 2024
7 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 20, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#124682 Suggest setting lifetime in borrowck error involving types … 93065a92224ea90af30a509b24d81adeca333ffd (link)
#124917 Check whether the next_node is else-less if in get_return_b… d87fa5596e9ef37deda8baa948c48358f77ccea0 (link)
#125106 coverage: Memoize and simplify counter expressions 18a0b36fe2acb699884660ee259c0adef9488b46 (link)
#125173 Remove Rvalue::CheckedBinaryOp 7f767d8b378412423b06df488bd62374dd0b9945 (link)
#125305 add some codegen tests for issue 120493 fdc8281df35d45f1608dd96dd1a17388cc78514d (link)
#125314 Add an experimental feature gate for global registration 50b4300c2343ddccc81ac36a6835184fa1d24117 (link)
#125318 Migrate run-make/rustdoc-scrape-examples-whitespace to `r… 68354eb15a67021f7d498388097640442c55588d (link)

previous master: 474bee7bf5

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 (be71fd4): 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)
-0.2% [-0.2%, -0.2%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 1.1%, secondary 2.0%)

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.9% [0.9%, 6.8%] 2
Regressions ❌
(secondary)
2.0% [2.0%, 2.0%] 2
Improvements ✅
(primary)
-4.3% [-4.3%, -4.3%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.1% [-4.3%, 6.8%] 3

Cycles

Results (primary -1.1%, secondary -5.0%)

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)
-1.1% [-1.3%, -1.0%] 2
Improvements ✅
(secondary)
-5.0% [-7.3%, -2.1%] 5
All ❌✅ (primary) -1.1% [-1.3%, -1.0%] 2

Binary size

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

Bootstrap: 670.162s -> 672.136s (0.29%)
Artifact size: 316.04 MiB -> 316.17 MiB (0.04%)

@matthiaskrgr matthiaskrgr deleted the rollup-4kfrh4n branch September 1, 2024 17:35
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. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.