Ehsan Akhgari wrote:
On 12/2/2013, 2:26 PM, Taras Glek wrote:
Mike Hommey wrote:
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
Incidentally, in those two weeks, I did two attempts at building
without unified sources, resulting in me filing 4 bugs in different
modules for problems caused by 6 different landings[1]. I think it is
time
to seriously think about having regular non-unified builds (bug
942167).
If that helps, I can do that on birch until that bug is fixed.
Speaking of which, there are essentially two classes of such errors:
- missing headers.
- namespace spilling.
The latter is due to one source doing "using namespace foo", and some
other source forgetting the same because, in the unified case, they
benefit from the other source doing it. I think in the light of unified
sources, we should forbid non-scoped use of "using".
That is:
using namespace foo;
would be forbidden, but
namespace bar {
using namespace foo;
}
wouldn't. In most cases, bar could be mozilla anyways.
Thoughts?
Engineering-heavy solution:
* You can extend one of clang header checks(eg only include what you
use) to make sure each cpp actually includes what they use.
include-what-you-use currently has some edge cases that it cannot
properly track (such as the case where only macros from a header get
used, which breaks a common #include patterns such as
<http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsGkAtoms.h#30>.
It has some other problems which I have hit before but I don't remember
them now. It's not entirely clear to me how easy these problems will be
to fix in IWYU.
* ditto re writing a clang analysis for namespace collisions.
Well technically in order to do something like that you'd just do the
semantic analysis phase and look at the compiler diagnostics. :-)
Some clever contributor like JCranmer could knock this out in no time.
We could then run these on debug builds on our infra without much extra
overhead.
Currently our static analysis infra only works on Linux. But note that
these two problems are not the only ones that we need to be worrying
about, and it's not clear to me whether it's worth for us to spend a lot
of effort in this analysis when a simple alternative exists (just
compiling the code in non-unified mode.)
mac support would be straight-forward.
Throw resources at this solution:
Alternatively, forcing a non-unified debug build on our infra would
catch most of these at higher infra cost.
See bug 942167.
To clarify my earlier email: I think the right approach here is what you
are suggesting in above bug and if it turns out someone contributes
these fun-to-write analyses, we can switch.
Taras
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
