Hi,

I just want to confirm if this is a bug in fpdoc from FPC v2.2.5

Here is the class interface

   // alias class will be removed soon.
   TVisOwnedQrySelect = class(TtiVisitorSelect)
   end deprecated;

This is the correct syntax for the usage of "deprecated" and it compiles fine with FPC.

Now when I run the fpdoc over that unit, fpdoc reports the following error:

../Source/Core/tiVisitorDB.pas(157,16): Expected ";" at token "Identifier deprecated"

Is fpdoc expecting a different syntax for "deprecated" keyword?

Regards,
- Graeme -

fpdoc also fails to generate HTML help output for that class (TVisOwnedQrySelect) and any other classes defined below it in the unit.

Regards,
- Graeme -

This is logical, as it has encountered an error.

The problem is in the pparser unit: it does not recognize 'deprecated' after a class type definition. This unit needs to be enhanced.

In fact, in the end it should parse a whole pascal unit, but that is a long term goal.

Michael.

OK. The reason I mentioned that it did not continue to generate the HTML output, is because sometimes fpdoc can handle "soft errors" like syntax errors in the documentation, yet it still dumps the content as is to the HTML output.

In this case it does not do that.

The problem is in the pparser unit: it does not recognize 'deprecated' after a class type definition. This unit needs to be enhanced.

I've never worked on a pascal parser yet, but I'll try and take a stab at the pparser unit - if nobody else beats me to it.

In fact, in the end it should parse a whole pascal unit, but that is a long term goal.

Couldn't fpdoc use the FPC parser instead of it's own? Or are they not so flexible. If fpdoc could, that would mean updating one parser would update both FPC and fpdoc, plus no code duplication.

Then again, I could be talking rubbish - like I said, I have never worked on a pascal parser before. ;-)

Regards,
- Graeme -

Some errors are indeed 'recoverable', when others are not.

The compiler parser pulls in way too much of the rest of the compiler, and is intertwined with the code generator, so that is not an option. Don't think I haven't considered it...

Michael.

Michael Van Canneyt wrote

compiler, and is intertwined with the code generator, so that is not an option. Don't think I haven't considered it...

I would never... :-)
Just thinking about it, a low-dependency pascal parser could be used for many things. fpdoc being one. JCF (Jedi Code Formatter) also has it's own pascal parser and now included with Lazarus, PasDoc, etc...

Each project seems to implement there own pascal parser - lots of duplicate work. But hey, that's life... :)

Regards,
- Graeme -

The fpdoc one is distributed with FPC as a package. Of course tools like pasdoc and JCF cannot assume FPC, so they must implement their own, since delphi doesn't distribute one.

I strongly encourage all people that need some form of pascal parsing to use and enhance the pparser unit. In due course, I'll need to enhance it to parse a complete unit (assembler excluded) - now it only parses the interface section.

Michael.

Michael Van Canneyt wrote

The fpdoc one is distributed with FPC as a package.

Brilliant idea and just what I meant.... being reusable by other projects will be a great bonus.

Of course tools like pasdoc and JCF cannot assume FPC, so they must implement their own, since delphi doesn't distribute one.

Very true!

Regards,
- Graeme -