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

No uninitalized report in a pre-returned match arm #126295

Merged
merged 1 commit into from
Jun 12, 2024

Conversation

linyihai
Copy link
Contributor

@linyihai linyihai commented Jun 12, 2024

This is an attemp to address #126133

@rustbot
Copy link
Collaborator

rustbot commented Jun 12, 2024

r? @pnkfelix

rustbot has assigned @pnkfelix.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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. labels Jun 12, 2024
@rust-log-analyzer

This comment has been minimized.

@pnkfelix
Copy link
Member

This solution does not cover all the cases I can imagine, but it is an improvement over the prior overall behavior, so I'm going to r+ it.

In particular, special casing return statements does not cover other kinds of non-local control-flow operations, such as break or continue. (But, to be clear:you cannot use a simple walk over the AST to identify which break/continue will cause the match arm to skip over the relevant use of the potentially uninitialized variable.)

The big picture problem here is that precisely identifying which match arms both A. can reach a use of the variable and B. fail to initialize the variable requires a control-flow analysis. Which you can get from the MIR, but you're trying to report a diagnostic with respect to the HIR.

(My suspicion is that a fully precise solution would work by using the MIR to identify the relevant spans that meet condition A and B in the previous paragraph, and then seek out the match arms here that overlap such spans. Or at least, that would be how I might investigate trying to attack a fully precise solution. But there are probably other rustc developers with alternative approaches in mind.)

@pnkfelix
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jun 12, 2024

📌 Commit 5d8f40a has been approved by pnkfelix

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 Jun 12, 2024
@pnkfelix
Copy link
Member

@bors rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 12, 2024
…llaumeGomez

Rollup of 9 pull requests

Successful merges:

 - rust-lang#126039 (Promote `arm64ec-pc-windows-msvc` to tier 2)
 - rust-lang#126075 (Remove `DebugWithInfcx` machinery)
 - rust-lang#126228 (Provide correct parent for nested anon const)
 - rust-lang#126232 (interpret: dyn trait metadata check: equate traits in a proper way)
 - rust-lang#126242 (Simplify provider api to improve llvm ir)
 - rust-lang#126294 (coverage: Replace the old span refiner with a single function)
 - rust-lang#126295 (No uninitalized report in a pre-returned match arm)
 - rust-lang#126312 (Update `rustc-perf` submodule)
 - rust-lang#126322 (Follow up to splitting core's PanicInfo and std's PanicInfo)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 876ef7f into rust-lang:master Jun 12, 2024
6 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jun 12, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jun 12, 2024
Rollup merge of rust-lang#126295 - linyihai:uninitalized-in-match-arm, r=pnkfelix

No uninitalized report in a pre-returned match arm

This is a attemp to address rust-lang#126133
@linyihai linyihai deleted the uninitalized-in-match-arm branch June 13, 2024 12:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

5 participants