-
Notifications
You must be signed in to change notification settings - Fork 258
[BUG] Analysis of uninitialized local fails at if without else #440
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
Comments
Shorter case: my_call: () -> (result: int) = {
if true {
result = EXIT_SUCCESS;
return;
}
result = EXIT_FAILURE;
} Outputs:
I'd expect this to just work since whatever comes after the if statement is a "implicit else branch" (in my eyes at least). |
As far as that analysis is concerned, your function looks like this, and that is the implicit else that it's referring to:
The requirement is currently that it must be assigned on every branch. The analysis would have to be a lot more sophisticated to determine that the In this case, the
Here's one that's more difficult to analyze:
|
Yes, I understand why it happens (thanks for writing down the explanation in any case, for other readers). But I still consider this a bug, for ergonomic reasons: It's pretty common to write code that has the happy case in the first if statement at the beginning of the function, and roll out the rest of the logic in (possibly) chain of extra if-statements. So I feel like at least the basic cases that consider this scenario ought to work, because that's a common way to start writing code. |
Agreed, I'm just saying that it would be good for a final version of this functionality to support that, but due to the complexities involved, I understand why the current state is the way it is. |
Thanks! This is intentional... the analysis doesn't do any control flow or data flow beyond checking that branch blocks do/don't initialize the local. Briefly, what is subtle to teach the compiler about will also be subtle for the human reading the code. Examples like this could be allowed, but start to get higher-cost (subtler to read/maintain) and also lower-benefit (occur less often). For example, it would have to take into account whether all possibly-nested branches in a branch tree do an early return. I understand the request though, I get similar things all the time with the C++ Core Guidelines Pro.Lifetime static analysis... a very common request is to support code like this:
The human can reason that That said, the day may come where I support at least simple uses like Thanks for the suggestion though, and thanks for understanding! |
Analysis of uninitialized local fails to see initialization which happens after single-if without else.
Reproduce Code
Version
latest
Command line
cppfront/cppfront $1.cpp2 -p
clang++-15 -Icppfront/include $1.cpp -std=c++20 -o $1
Expected result
Compilation success
Actual result/error
Additional context
With return, both paths init and return.
Without return, there is double initialization, but error is the same.
The text was updated successfully, but these errors were encountered: