Lint this c.u. again not compiling again
Tue, 2009-02-03 13:18 — Niek
Prolint.p only compiles the c.u. when it needs Listing and/or Xref.
There is a construction which will or will not enter the compile-loop:
Line 751:
IF NeedListing OR NeedXref THEN compiler-loop: DO compilerLoopNum = 1 TO 2:
but there is also a construction which passes ? (unknown) to the compiler-statement when Listing or Xref is not required.
Line 756:
LISTING VALUE(IF NeedListing THEN listingfile ELSE ?)
XREF VALUE(IF NeedXref THEN xreffile ELSE ?)
I think the first can and shoul be removed so compile-errors are detected even when no xref or listing is needed for any rules.
agreed?
- Login to post comments
Re: Lint this c.u. again not compiling again
Hi Niek,
I am not sure if I agree. Compile errors are syntax errors, right? Proparse catches all syntax errors so compiling seems like a waste of time to me, unless the compiler is used for creating an xref-file.
You are right if the compiler can catch a syntax error that Proparse does not catch. Does it? I mean, if you have an example of such an error I guess that John (John Green, the Proparse designer) would like to know.
Apart from my "waste of time" argument I agree it can't hurt to invoke the compiler... but still I'd prefer to ensure that Proparse is as good a parser as the compiler is.
Re: Lint this c.u. again not compiling again
It's the other way around. If it compiles, then it should parse... and if it doesn't parse, then there's a bug in Proparse that we want to know about.
Proparse does not validate the code. It never will. Only the compiler can do that.
The compiler is very fast, so there should not be any harm in always doing the compile. If it doesn't compile, then don't bother parsing it! Also note that it is very common to lint a directory full of .p files even though many of those files are known not to compile. It is important that in Prolint it is always easy to hide or filter those compile errors. (I think that's already the case.)
I agree with the original post, too. It is also often useful to have Prolint report compile errors in its output.
ok ok ok I have changed it:
ok ok ok I have changed it: Prolint always compiles even if it does not need an xref file.
I have also received some more mods from Niek, am looking into that now.
Thanks Niek!!!!!
run ip_iets.procedure
assign cvar1 = 'hallo'.
does not compile, but parses with an error on rule tablename???
field cvar1 must be qualified with tablename
Furthermore I have now changed Prolint so it will publish the compile-errors with their line-numbers
Re: Lint this c.u. again not compiling again
LOL - that's a convincing example!
Ok so prolint should always compile the c.u. even if an XREF or Listing is not requested. I will do that.
Publishing line-numbers is a nice improvement, would you like to share that modification?