On 2/13/2012 2:43 PM, Kristian Rietveld wrote:
On 2/13/12 9:21 PM, Joshua Cranmer wrote:
On 2/10/2012 10:14 AM, Lionel Dricot wrote:
Another issue I recall from when I discussed this at the LLVM
developer's meeting was the "#ifdef issue": how do you handle the fact
that, after preprocessing, not all the original source code gets "seen"
by the compiler? The mental model I've had for a long time is to somehow
be able to merge the records of two different compile runs into a single
indexing output.
I think that is indeed a very interesting and also important issue. I
have been thinking about code bases with different "backends". Some
source files only get compiled on Linux, some files only on OS X (in
particular objective-C code to glue with Cocoa). Still, you would
really want to see all code recognized in the DXR interface.
Some methodology to merge the records produced by different
compilers/machines compiling the same code revision seems indeed
necessary. Though I am a bit worried which problems we would get to
solve when parsing records for the same source file produced by
different compilers. For example, what would happen with macros that
expand differently depending on the machine/platform it was
preprocessed on? (Though in that case it would be quite cool to
actually show both macro expansions tagged with the platform it was
produced on).
Well, given that there are already examples where people define the same
macro with different definitions in a single compilation run (e.g.,
let's-fake-templates-in-C), the use case of macros would need to be
handled in the general case anyways.
But I've kind of imagined something visually like:
foo
+ Defined in widget/unix/foo.c (in Linux mode)
+ Defined in widget/mac/foo.c (in OS X mode)
+ Defined in widget/windows/foo.c (in Windows mode)
[etc]
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
