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.