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

Ignore unwinding edges when checking for unconditional recursion #92889

Merged
merged 1 commit into from
Jan 27, 2022

Conversation

tmiasko
Copy link
Contributor

@tmiasko tmiasko commented Jan 14, 2022

The unconditional recursion lint determines if all execution paths
eventually lead to a self-recursive call.

The implementation always follows unwinding edges which limits its
practical utility. For example, it would not lint function f because a
call to g might unwind. It also wouldn't lint function h because an
overflow check preceding the self-recursive call might unwind:

pub fn f() {
    g();
    f();
}

pub fn g() { /* ... */ }

pub fn h(a: usize) {
  h(a + 1);
}

To avoid the issue, assume that terminators that might continue
execution along non-unwinding edges do so.

Fixes #78474.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 14, 2022
@rust-highfive
Copy link
Collaborator

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 14, 2022
The unconditional recursion lint determines if all execution paths
eventually lead to a self-recursive call.

The implementation always follows unwinding edges which limits its
practical utility. For example, it would not lint function `f` because a
call to `g` might unwind. It also wouldn't lint function `h` because an
overflow check preceding the self-recursive call might unwind:

```rust
pub fn f() {
    g();
    f();
}

pub fn g() { /* ... */ }

pub fn h(a: usize) {
  h(a + 1);
}
```

To avoid the issue, assume that terminators that might continue
execution along non-unwinding edges do so.
@tmiasko
Copy link
Contributor Author

tmiasko commented Jan 26, 2022

r? @ecstatic-morse

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Jan 27, 2022

This seems strictly better while preserving existing behavior for the cases in #54444. There might be an interpretation of "lints have zero false positives" and "unconditional recursion" that would cause people to disagree with this change, but I think that interpretation is too narrow.

Thanks tmiasko!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jan 27, 2022

📌 Commit 10b722c has been approved by ecstatic-morse

@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 Jan 27, 2022
@bors
Copy link
Contributor

bors commented Jan 27, 2022

⌛ Testing commit 10b722c with merge 21b4a9c...

@bors
Copy link
Contributor

bors commented Jan 27, 2022

☀️ Test successful - checks-actions
Approved by: ecstatic-morse
Pushing 21b4a9c to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 27, 2022
@bors bors merged commit 21b4a9c into rust-lang:master Jan 27, 2022
@rustbot rustbot added this to the 1.60.0 milestone Jan 27, 2022
@tmiasko tmiasko deleted the unbounded-recursion branch January 27, 2022 09:49
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (21b4a9c): comparison url.

Summary: This benchmark run shows 36 relevant regressions 😿 to instruction counts.

  • Average relevant regression: 2.9%
  • Largest regression in instruction counts: 14.3% on full builds of projection-caching check

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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

@tmiasko
Copy link
Contributor Author

tmiasko commented Jan 29, 2022

The performance regression will be addressed by changes from #93381.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Jan 29, 2022
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. perf-regression-triaged The performance regression has been triaged. 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.

unconditional_recursion lint doesn't work with struct update syntax
7 participants