[fpc-devel] Adding compiler directives?

[Jonas Maebe]

On 18 Jan 2012, at 01:07, Paul Robinson wrote:

> I would like to ask whether there's a rule or policy on new compiler  
> directives.

In general: the fewer, the merrier :)

> The new directives are first, for printing capability:

Printing-related features is not something that we'd ordinarily put  
into the compiler. Source code formatting (for whatever purpose) is  
left to other -specialised- tools, such as
* ptop: general purpose source code formatter (included with FPC)
* Lazarus: includes various source code formatting capabilities
* maybe another tool not yet written, possibly based on other existing  
code

Such tools could be extended to check for specially formatted comments  
(such as { #PRINT ON }).

> Then there is the second part of this inquiry which is:
>
> $CROSS  - various options I haven't decided yet
>
> A most desperately missing feature - Cross Reference generation.  I  
> can always write a cross-reference program, and in fact I'm working  
> on one because I can't find the nice one I had that was written  
> about 20 years ago that did much of what I'm thinking of now, but a  
> cross-reference function should be part of the compiler since the  
> compiler "knows" which reference the person is referring to

There is actually already some code for that in the compiler, although  
it is quite outdated and no longer used. It's in the compiler/ 
browcol.pas unit. It writes (wrote) out symbol browsing information  
that can (could) be used by the fp IDE. I don't think it included back  
references from places where those symbols are used inside the code  
though, only about where they are defined.

There's also the -vp compiler option, which writes out a file called  
"tree.log" that represents the parse tree (this option primarily  
exists to help debugging the compiler). It would not be very difficult  
to extend that output with adding for each loadn also the unit/line/ 
column information for each referenced symbol. Its format was however  
not designed to be easily machine-parseable, and changes from time to  
time as fields get added to or removed from node types in the compiler.

There's also the Lazarus IDE, which already contains code to extract  
all of tha information, both regarding definitions and uses (it needs  
it for its code navigation functionality). So maybe adding some kind  
of "dump" facility to that code would be better. In fact, in general  
simply navigating the source code in Lazarus should offer you the same  
information on demand as a separate cross-reference would (jump to  
symbol definition immediately lands you at that definition, rather  
than that you have to manually go looking through papers/source files  
for the right source file and line number based on a comment).


Jonas