Hi,

Does FPC include a "general purpose" object pascal parser we can use in our own projects? Obviously the FPC compiler itself has a parser, but is that a free-standing unit or class we can use in other projects? I know fpdoc needs to parse source code as well, but I don't know if it uses the same parser as the FPC compiler.

I don't want to create 'yet another object pascal parser', and I can't use existing Delphi ones, because it needs to support the FPC language syntax (and support for include files) specifically.

Have a look at fpc/packages/passrc.

Regards,

Adriaan van Os

In our previous episode, Graeme Geldenhuys said:

No, it uses fcl-passrc.

A third, more limited parser exists inside ptop and other highlighting and source beautifying tools.

I don't want to create 'yet another object pascal parser', and I can't use existing Delphi ones, because it needs to support the FPC language syntax (and support for include files) specifically.

Afaik include files are compatible to Dlephi, except that FPC afaik recompiles units if they change. But yes, I agree that on average Delphi tools don't support comfortably what the delphi compiler suports.

Marco van de Voort wrote

> projects? I know fpdoc needs to parse source code as well, but I don't > know if it uses the same parser as the FPC compiler. No, it uses fcl-passrc.

Perfect, thanks. Now my next question is, how up-to-date is the parser [compared to the FPC parser]? Looking at the repository history for the fcl-passrc directory, it looks like things are being updated. February had a large update from Mattias.

A third, more limited parser exists inside ptop and other highlighting and source beautifying tools.

I would prefer to use something included with FPC - that at least promotes the idea that it will stay updated as new language features get added to FPC.

Yes. It now parses the whole of the packages directory. That was the contract for Mattias.

This is the idea for passrc.

Michael.

In our previous episode, Graeme Geldenhuys said:

It roughly works, but there are problematic constructs. IIRC it doesn't support some of the deprecated options.

The rest was mentioned to be complete. I think fcl-passrc is the most sane choice by far, both the parser, and because it is set up as a library.

That has been fixed in trunk meanwhile, I think.

Michael.

Marco van de Voort het geskryf:

It roughly works, but there are problematic constructs. IIRC it doesn't support some of the deprecated options.

:-) Isn't that a good thing. After all, something marked as deprecated can be removed at any time. The parser simply promotes the idea of cleaning up your code. ;-)

Thanks to all that replied, I'll definitely use fcl-passrc in my project. And looking at fpdoc source code, I have a nice example of how to use it too.

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

Hmm, I'd rather call that an extremely bad thing, since deprecated is mainly useful for documentation. Moreover, if that were the case, the compiler should forbid that, not the doc parser.

Seriously however, these are exceptions, rather than the rule. Mattias fixed really a lot. Except maybe all the constructs recently added to FPC. (Paul's D2006 features, case of string etc).

If I understand Michael's remarks, about what Mattias goals were, correctly, that's logical, since those features are not used in packages/

All the talk about the Pascal parser in fcl-passrc got me interested recently. I did some experiments, and I thought I mention here:

1. I added a simplest example how to use fcl-passrc to the wiki:

http://wiki.freepascal.org/fcl-passrc

2. And reported a couple of bugs found in fpdoc (tested on PasDoc's testsuite):

http://bugs.freepascal.org/view.php?id=16340
http://bugs.freepascal.org/view.php?id=16341
http://bugs.freepascal.org/view.php?id=16342
http://bugs.freepascal.org/view.php?id=16343
http://bugs.freepascal.org/view.php?id=16344
http://bugs.freepascal.org/view.php?id=16345
http://bugs.freepascal.org/view.php?id=16346
http://bugs.freepascal.org/view.php?id=16347

Some other failures were found (see the testcase: ok_dispid_method.pas, ok_dot_unitname.pas in pasdoc svn), but these were language features not handled by the FPC at all for now.

Also, program files are not parsed by fcl-passrc, it's limited to units for now. We would like to be able to eventually parse program files too. Yes, they make sense even in a documentation generator, since you can then e.g. gather all units used by the program and get your list of units to make docs from there. An optional, sure (in general, we could pick too few or too many units) but for some situations a useful feature (not finished in PasDoc, but planned).

fcl-passrc is quite capable already, it successfully parsed a lot of quirky sources, so it's really great already :) Hope my reports hope to push it even better :)

Michalis

This is useful, thank you :-)

As soon as I get around to some bugfixing, I'll have a look at these.

I am all for it. It should not be hard to handle this; It's like parsing an implementation block, with an extra flag that it should expect a begin/end instead of initialization/finalization block.

Michael.

Hi!

I don't know whether you know that or fcl-passrc supports that, but the begin/end block is also possible in a unit:

=== code begin ===
unit unitbegin;
interface
function Foo: Integer;
implementation
function Foo: Integer;
begin
   Foo := 42;
end;
begin
   Writeln(Foo);
end.
=== code end ===

This compiles without errors and the begin/end block is treated as an initialization block.

Regards,
Sven

It supports that, but for a program, the begin/end is mandatory, so fcl-passrc needs to be notified. Like I said, it should be easily added.

Michael.

In our previous episode, Michael Van Canneyt said:

As soon as I get around to some bugfixing, I'll have a 't we create some testsuite for fcl-passrc? (or have a flag in the

existing testsuite to exclude tests from fcl-passrc or real compiler tests or so?)

I created a VERY small test sample in utils/fpdoc, it tests 'strange' cases. It would indeed be a good idea to create a testsuite in fcl-passrc itself.

Michael.

Wouldn't it be enough just to let it scan/parse the whole fpc test suite :)?

Good idea. Are all possible constructs in FPC in the testsuite ?

Michael.

In our previous episode, Florian Klaempfl said:

That's what I mean with adding flags to the testsuite. (to exclude some tests from the compiler and vice versa, since there are always problems and gotchas)

Michael Van Canneyt wrote

Good idea. Are all possible constructs in FPC in the testsuite ?

Probably not, but a lot of them are.

Jonas