Running the preprocessor in reverse

[jyavner_BulkUCE at member dot fsf dot org]

Myer is a coupling/cohesion analyser based on a patched gcc.  It computes
the marginal cost of each identifier to its module's coupling and cohesion,
displaying the results in HTML as colorized source code.

The gcc patches provide a new dump option "-d@", which dumps the
identifier-stream, showing for each the (line,col) from the input file and
the UID from the parse-tree.

The patches need more work.  Identifiers declared multiple times (such as
functions) sometimes show up with multiple UIDs, that gcc is obviously
merging internally, but I can't figure out where this is happening.  Also,
my identifier-stream format is probably too specific to Myer's needs and
should be generalized before adding it to mainline gcc.

Myer "runs the preprocessor in reverse", propagating info from the
parse-tree back to the source spots it came from.  It synthesizes analyses
for macro definitions by merging all spots where the macro is invoked.  It
colorizes .h files by merging the identifier-streams of all the compilation
units in a program.  Is this a first?  It was remarkably easy to implement
by using the new error-reporting system in gcc-3.

The reverse-preprocessor thing is mostly done, but still fails to properly
merge some .h files.  When Myer analyses gcc, about 10% of gcc's .h files
fail to merge.

So far, the "per-identifier marginal cost to coupling/cohesion" thing is a
bit disappointing.  I wanted it to highlight bug-prone areas of code, but
the results don't seem interesting.  Perhaps my marginal-cost formulas need
serious tweaking.  I'm hoping there is overlap between the compiler people
and the software-metrics people.  Anyone interested in looking into this a
bit?  All opinions gratefully accepted!


Myer's freshmeat page:
  http://freshmeat.net/projects/myer

A description of the output format produced by my -d@ option to gcc:
  http://www.nongnu.org/myer/README-phases.html