I recently came across a subtle problem with semi-colon placement, when used in
*particular* v3.8 development versions (in Windows). It took me some time to
track down, and to figure out a simple test to reproduce it:
---------------
#version 3.8;
global_settings{assumed_gamma 1.0}

#declare VEC = <.3,.5,.7>;

#macro MY_MACRO(FOO)
#local BAR = FOO;
<BAR.x,BAR.y,BAR.z>;
#end

#declare XYZ_POS = MY_MACRO(VEC);
---------------
In  versions 9811560+av591 and 9893777+av622, the above code works without a
problem. But in later versions 10013324+av645, 10064268+av691, and
10064738+av694 , the semi-colon after
          <BAR.x,BAR.y,BAR.z>;
causes a fatal error.

A macro is the only structure to be sensitive to this, that I have discovered so
far-- perhaps because it's one of the few code structures that, depending on
use, does not specifically need a semi-colon after its 'result'.

Maybe the later development versions 'tightened up' the rules of semi-colon use
in general?

In any case, there are two ways to fix this in the later versions:
1) Put a semi-colon after  <BAR.x,BAR.y,BAR.z> but NOT after
#declare XYZ_POS = MY_MACRO(VEC)
2) REVERSE that order

In the earlier versions, semi-colons can be used in both places at once-- or
like 1) or 2) as well. (I haven't yet tried any v3.7xx to see what happens
there.)

Just something to be aware of for the future.

Post a reply to this message

On 10/28/20 12:40 AM, Kenneth wrote:
> I recently came across a subtle problem with semi-colon placement, when used in
> *particular* v3.8 development versions (in Windows). It took me some time to
> track down, and to figure out a simple test to reproduce it:
> ---------------
> #version 3.8;
> global_settings{assumed_gamma 1.0}
> 
> #declare VEC = <.3,.5,.7>;
> 
> #macro MY_MACRO(FOO)
> #local BAR = FOO;
> <BAR.x,BAR.y,BAR.z>;
> #end
> 
> #declare XYZ_POS = MY_MACRO(VEC);
> ---------------
...
> 
> Maybe the later development versions 'tightened up' the rules of semi-colon use
> in general?
> 
My guess is double semicolons are no longer allowed after Christoph's 
parser performance changes in v3.8.

One thing done was to implement a fast scan ahead which looks for the 
end of if blocks for example so they can be digested / skipped in 
chunks. Here I think it scans ahead for the required trailing ; finding 
the last one, but what is just prior isn't what's expected, but rather a 
semicolon preceding the last found.

I suspect your test case could be just

#declare VEC = <.3,.5,.7>;;

Bill P.

Post a reply to this message