xsharp.eu • Ambiguity between local access and global define
Page 1 of 1

Ambiguity between local access and global define

Posted: Tue Jul 16, 2024 3:07 pm
by baramuse
Hi,

we've troubleshoot some of our ported code today and found out we had an ambiguous variable access between a local access and a global define.
The Global define is not even part of the current project but from another projected referenced in the solution
We've disabled the implicit namespace compiler option.
here are the culprits :
in project1.class1

Code: Select all

CLASS LocDetArray
	ACCESS STATUT_CTRL()
		RETURN ( SELF:FIELDGET( #STATUT ) = STATUT_CTRL )
END CLASS
in project2, global :

Code: Select all

DEFINE STATUT_CTRL	 	  		:= "4"
In our case we were having a STACKOVERFLOW crash as the access would go into an infinite loop.
So now we prefix the LocFacComLib.Functions.STATUT_CTRL to get the global define to lift the ambiguity.

How could we further prevent this ?
Can't the compiler warn us, like it does for other ambigous calls ?

Regards.

Re: Ambiguity between local access and global define

Posted: Tue Jul 16, 2024 8:11 pm
by Chris
Hi Basile,

In order to prevent this, you'd need to enable the compiler project option "Enforce SELF", which will make VO require to use "SELF:" for accessing any class variables/properties/methods as in VO. Without SELF: in your code, when this option is enabled, the compiler would resolve the identifier to the DEFINE/GLOBAL instead.

But unfortunately I see this isn't working correctly now in the compiler. I will open a report about this, including a suggestion to show a warning about ambiguity even when this option is not enabled. Since you are a subscriber, I will send you an updated compiler as soon as this is fixed!

Re: Ambiguity between local access and global define

Posted: Tue Jul 16, 2024 8:34 pm
by Chris
Ah, I just noticed that VO does require the use of SELF: for calling methods and properties, but not for accessing class variables! This is so bad...

In X#, the /enforceself option covers all cases and I think we should keep it this way. But it means it's not the best solution in your case, since enforcing the use of self: everywhere will probaly require adding this in several places where it was needed in the original VO code (even designers generate such code). The fix we need to make is to make the compiler give priority to GLOBALs/DEFINEs, instead of same named ACCESS/ASSIGNs (and warn about the ambiguity).