[fpc-devel] Troubles with FPDOC in 2.5.1 and 2.4.1

[Michael Van Canneyt]

On Fri, 14 May 2010, Mattias Gaertner wrote:

> On Fri, 14 May 2010 14:33:57 +0200
> Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:
>
>> Marco van de Voort het geskryf:
>>>
>>> 1) I would particularly be interested if there is a difference between 2.4.1
>>> (say a week old maximally) and 2.5.1 (likewise). Before my holiday I
>>> committed a fix or two.
>>
>> Marco, you are off the hook. :-)
>>
>>
>> Damn I love the 'git bisect' command. ;-)  Anyway the problem is
>> sub-divided. The errors for 'label' and 'xxx of byte' syntax is introduced
>> in r14938. Sorry Michael, that the big patch from Mattias. Now you will
>> understand why I *hate* such big single commits. Where do you start looking
>> for the problem??   You should ask Mattias for a refund. ;-)
>
> I can send you my 49 smaller patches. But I doubt that would help.
> AFAIK deprecated and label were not supported, so I did not break
> that.

This is correct. I did (attempt to) add the support for it.

> As I wrote on the fpc mailing list:
> I extended the fcl parser to parse the FCL code, which does
> not use all the FPC features (tons of modifiers, special compiler directives, nested classes) and not all the Delphi "bugs" like ommitting semicolons.
> It took some effort to extend the fcl parser without breaking
> compatibility and having extendable code.
> Pre- and post-modifiers make parsers ugly and complicated, because
> there is no single start/terminal token anymore and because some
> modifiers can be identifiers, requiring bigger lookaheads.

Tell me about it :/

> The fcl
> parser design requires to know the node type before start parsing the
> node. This makes implementing lookahead somewhat more difficult
> (compared to the codetools). That's why I added some more context
> information. But its parser design is still not the best for
> pre/postmodifiers. OTOH you get a nice class hierarchy: When the parser
> is changed affected code is spotted easier than with the codetools.
>
> In short:
> It is difficult to add pre/postmodifiers to the fcl parser, because of
> its design. But its design is good for tools like fpdoc. (Note: the fcl 
> parser was designed by Sebastian Guenther).

100% correct, and the 'breakage' is entirely my fault; Parsers are not
my strongest point (in fact, I hate them, but what can I do...).

Michael.