On 12/20/24 07:43, Kenneth wrote:
> #declare FOO = 27;  //*3
> ...just as a way to remind myself to try multiplying the 27 by 3 later.
> 
> As-is, the scene parsed and rendered fine. But what  I*meant* to write was:
> #declare FOO=27; //   *3
> 
> SO...
> While continuing to experiment with the scene, I happened to use /* and */ to
> comment-out that entire block of code-- which also contained the line with the
> mistake.
> 
> Now, the scene fails:  "Parse error-- No  */ closing comment found." The parser
> apparently sees  part of my   //*3  as  /* -- but only when
> another 'complete'  /* ...*/  comment block is enclosing it.
> 
> After finding my error, what surprised me is that the scene originally parsed
> OK...when it should not have, in my opinion. I think POV-ray should have caught
> my initial mistake, and with the same error message.

It's my view '//*3' isn't a mistake, but a valid comment which the 
parser should be ignoring no matter whether it's nested inside a /*..*/ 
block comment or not.

Leroy's test case of:

/* wrrtr
//*3
fdssdds
*/
*/

is a good one because the integrated editor in the windows binaries must 
be ignoring '//' and anything after as a stand alone comment.

When I bring up his example in vim/gvim the syntax checking for both 
POV-Ray 3.7 and yuqk highlight that last '*/' as an error. So, in vim 
too the '//' is treated as a stand alone comment whether nested in 
another comment or not.

---
FWIW.

Your problem code is something the newer parser clipka coded up reports 
better than the older parser.

The follow code:

/*  this is line 2

#declare FOO = 27;  //*3

*/

Generates messages like: "Parse Error: No */ closing comment found." in 
the older parsers.

The newer parser (in the POV-Ray master branch and a derivative of it is 
the parser used in yuqk) will kick out messages like:

"File 'kenneth.pov' line 2: Parse Error: Unterminated block comment in 
input file."

Or yuqk's:

File 'kenneth.pov' line 2:
Parse Error:
Unterminated block comment in input file.

The messages from the newer parser give better hints as to where to 
start looking for issues with block commenting.

---

Anyhow. I agree this a bug in all parser versions - but due flagging 
your valid code comments as a problem and treating Leroy's example as OK.

Bill P.

Post a reply to this message