I have been using TPasSrcAnalysis (passrcutil.pp) to examine source code, and it works well for most use cases. But it lacks some flexibility when used for source which doesn't follow certain conventions.
Specifically, it doesn't allow you to have code where include files (.inc) are in a directory other than the one where the source is located. The file resolver, scanner, and parser have the tools needed... you just can't access them because they're hidden away in private members with no API to configure them. To overcome this, you basically have to re-implement the class, and in some cases the storage container since its in the implementation section of the unit.
I think it would be useful to make it a little more configurable. For example, add properties for:
IncludePaths: TStrings;
Defines: TStrings;
ContainerClassType: TPasTreeContainerClass; // does not exist ATM
They can be accessed and maintained before Parse gets called.
CheckParser could be modified to use these values when creating/configuring the internal members:
FResolver // Call .AddIncludePath for each value in IncludePaths
FContainer // := FContainerClassType.Create;
FScanner // Call .AddDefine for each item in Defines
These measures eliminate the need to subclass for most use cases.
Just thinking out loud. Feedback appreciated.