[VFP] Bogus compiler warning about not used variable, when /fox2 is enabled

[cpyrgas]

Following results to error XS0165: Use of possibly unassigned local variable 'u'

#pragma options(initlocals,off)
#pragma options(fox2,on) // happens with fox2+ enabled only
FUNCTION Start( ) AS VOID 
LOCAL u
u := 1  // error XS0165

Also same warning is reported in this case, but it is correct in this case I assume?

#pragma options(initlocals,off)
#pragma options(fox2,off) // doesn't matter for this one
PROCEDURE Test1()
LOCAL u
DIMENSION u[100] // error XS0165
RETURN

[RobertvanderHulst]

The reason for XS10165 in this code with /fox2 is that when u is an array, then the assignment u := 1 will fill the whole array with the value 1.
For that reason the assignment is translated into: u := XSharp.VFP.Functions.__FoxAssign(u, 1)
The __FoxAssign function needs to know the original type of u to decide what to do.

[RobertvanderHulst]

In the second example the compiler outputs this:
u := XSharp.VFP.Functions.__FoxRedim(u, 100u, 0u)
The FoxPro dimension command can be used to redimension an existing array.

[cpyrgas]

OK, I understand. Maybe in the future we can implement a compiler option (re-introduce fox1?) that enables/disables some of such VFP features, so people can still use the VFP dialect, but let the compiler create more robust code (and make more compile-time checks).

[RobertvanderHulst]

Chris
The __FoxAssign() code only gets generated with /fox2 enabled IIRC.