Open
Bug 1424694
Opened 7 years ago
Updated 2 years ago
Analysis to reflow if...else statements
Categories
(Developer Infrastructure :: Source Code Analysis, enhancement)
Tracking
(firefox59 affected)
NEW
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.
Comment 1•7 years ago
|
||
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.
Updated•7 years ago
|
Product: Core → Firefox Build System
Updated•7 years ago
|
Updated•6 years ago
|
Severity: normal → enhancement
Updated•2 years ago
|
Product: Firefox Build System → Developer Infrastructure
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•