Open Bug 1424694 Opened 7 years ago Updated 2 years ago

Analysis to reflow if...else statements

Categories

(Developer Infrastructure :: Source Code Analysis, enhancement)

x86
Linux
enhancement

Tracking

(firefox59 affected)

Tracking Status
firefox59 --- affected

People

(Reporter: andi, Unassigned)

References

(Blocks 1 open bug)

Details

Sylvestre came up with the idea that it would be nice to introduce into our clang base analysis the possibility to detect and even reflow blocks like: >>if (!foo()) >> ba1(1); >>else >> bar2(); Obviously a benefit of the reflow would be more accuracy when looking other the code. >>if (foo()) >> bar2(); >>else >> bar1(); Of course this is a trivial example but this can also be extrapolated to more generic cases. One issue that i see here is with classes that have overloaded operator ! like: >>class PI >>{ >>public: >> PI() = default; >> >> int foo = 10; >> >> bool operator!() { >> return !foo; >> } >>}; and in a context like this: >> PI a; >> if (a) { >> // do something >> } else { >> // do something else >> } We don't want this to be detected as a potential reflow situation since a reflow in this case would result in build error since no match conversion can be found from PI to bool.
Sounds like a good idea. However I have a concern that has to do with block sizes. It is quite commonly accepted that smaller blocks should be placed first, and I think that we definitely don't want something like this: if (!foo) { Smallblock; } else { B; I; G; B; L; O; C; K; } to be reversed (the big block could be much bigger). We will probably need to set a maximum ratio in terms of number of lines.
Product: Core → Firefox Build System
Severity: normal → enhancement
Product: Firefox Build System → Developer Infrastructure
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.