GNOME Bugzilla – Bug 574352
variable initialized in do-while loop not recognized.
Last modified: 2018-05-22 13:18:48 UTC
Please describe the problem: If a variable is initialized in a do-while loop iteration (which is guaranteed to be executed at least once), the symantic analyzer still complains the variable is not initialized. Steps to reproduce: public virtual Vector sample(bool open) { ┊ ┊ ┊ double x, y, z; ┊ ┊ ┊ double r; ┊ ┊ ┊ Vector point; ┊ ┊ ┊ Sense s = Sense.OUT; ┊ ┊ ┊ do{ ┊ ┊ ┊ ┊ Gsl.Randist.dir_3d( rng, out x, out y, out z); ┊ ┊ ┊ ┊ r = rng.uniform(); ┊ ┊ ┊ ┊ r = cbrt(r) * bounding_radius; ┊ ┊ ┊ ┊ point = Vector(x * r, y * r, z * r); ┊ ┊ ┊ ┊ body_to_world(ref point); ┊ ┊ ┊ ┊ s = sense(point); ┊ ┊ ┊ } while(s == Sense.OUT || (open && s == Sense.ON)); ┊ ┊ ┊ return point; ┊ ┊ } Actual results: Compilation failure with error possibly not initialized variable point. Expected results: Does this happen every time? Other information: the work around is to set point when define it. But this would be a duplication of work since it is going to be initizized in the do-while loop.
Created attachment 152156 [details] [review] simplify the do statement The do statement currently check for the condition at the beginning of the loop. This makes the control flow analyzer work harder to understand that the first time the body of the loop is being executed. This patch checks for the condition at the end of the loop, which looks like more natural to me for the control flow. I don't know if this will break anything else, but tests don't fail and the generated C code is even easier to read.
Doesn't this break continue statements?
(In reply to comment #2) > Doesn't this break continue statements? You're right, I'm sorry. What about adding an extra property like Loop.is_do_loop or Loop.reaches_end to always connect the last block of the loop body to the block after the loop?
*** Bug 601340 has been marked as a duplicate of this bug. ***
The proper way to solve this is to rewrite the loop with goto statements internally, as far as I can tell. This would avoid the problematic 'first' variable that gets generated now when rewriting the do loop with a while (true) loop.
I think the proper way to solve this is to do all the semantic and control flow analysis before breaking the code apart and rewriting it. It would also make some of the code more easily understandable.
This would introduce more complexity into flow analysis as it would require the flow analyzer to deal with error handling and reachability analysis within (conditional) subexpressions. Simplifying the code tree as early as possible sounds like the best approach to me. Why do you think it would be better to move the simplifications to a later stage?
Because, as can be seen in this bug, sometimes the simplifications loose some of the semantic meaning the code has. So the possibilities are to either have buggy analysis, or to figure out some very special, probably very ugly, way to do those simplifications, which in the end is (in my opinion) more trouble than making flow analysis smarter.
Created attachment 166434 [details] [review] Fix do-while statement flow analysis. Fixes bug 574352.
Comment on attachment 166434 [details] [review] Fix do-while statement flow analysis. As discussed on IRC, the plan is to change the code generator in a way that makes it possible to drop the code simplifications in the Vala AST completely.
*** Bug 645771 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/27.