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•3 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
•