[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.