namespace vs. property confuses the compiler

[wriedmann]

The code

property System as logic auto

constructor()

	System.Diagnostics.Debug.WriteLine( "Hi" )

	return

end class

gives the errors

warning XS9043: 'System' is ambiguous. Could be Property 'nsvsprop.System' in NamespaceVsProperty or Namespace 'System' in mscorlib. Using the first one. error XS1061: 'logic' does not contain a definition for 'Diagnostics' and no accessible extension method 'Diagnostics' accepting a first argument of type 'logic' could be found (are you missing a using directive or an assembly reference?)

This is new for 2.20 - it compiled correctly in previous versions.

[cpyrgas]

This actually seems to be working ok, even without the "GLOBAL::" clause, but /allowdot needs to be disabled.

Problem here seems to be that /allowdot is set to enabled by default in the Core dialect. Is this intentional?

I will adjust XIDE to always emit /allowdot-, when the option is not checked in the app properties. Ah, just realized XIDE does not have this option in the properties window at all! Probably because I hate it so much... So it always defaults to enabled for the core dialect.

Wolfgang, am I right that you are using the Core dialect for this code? For now, please add

/allowdot-

in the compiler options for the app.

[wriedmann]

Hi Chris,

yes, this code is using the Core dialect (and XIDE).

Wolfgang

[RobertvanderHulst]

Chris, Yes, the fact that /allowdot is enabled by default in the Core dialect is by design. Robert

[cpyrgas]

I have adjusted XIDE so that it always passes /allowdot- (unless specified otherwise in the app options) to the compiler and the problem is fixed now.

[cpyrgas]

Actually the recent change in the compiler has caused some problems. I am getting bogus errors in my apps for accessing static members, but can't reproduce in a small sample yet. I can reproduce a failed to emit module error though, maybe fixing that will fix my other issues, too:

// core dialect, allowdot-
// error XS7038: Failed to emit module 'coretest': Unable to determine specific cause of the failure.
FUNCTION Start( ) AS VOID
	Nothing.Something(123)
RETURN

[nvkokkalis]

Interesting, I will check Chris!

[cpyrgas]

Found the cause of one of the other cases, it's similar to Wolfgang's original report, but now with /allowdot disabled:

(note that the problem happens only when the code is inside a STATIC method. If it's in an instance method, then no error is reported!)

// core dialect, /allowdowt- (disabled)
// error XS0176: Member 'MyEnum.m1' cannot be accessed with an instance reference; qualify it with a type name instead
ENUM MyEnum 
	MEMBER m1
	MEMBER m2
END ENUM

CLASS ColorClass
	PROPERTY MyEnum AS MyEnum AUTO

	STATIC METHOD Test() AS VOID
		LOCAL e := MyEnum.m1 AS MyEnum // error XS0176
		IF e == MyEnum.m1 // error XS0176
			NOP
		END IF
// no error reported here:
	METHOD InstanceTest() AS VOID
		LOCAL e := MyEnum.m1 AS MyEnum // no error
		IF e == MyEnum.m1 // no error
			NOP
		END IF

END CLASS

Not sure if it's a new bug, or it just surfaced now that I am issuing /allowdot- in XIDE

[cpyrgas]

Another problem, this happens with code inside nested classes only. Following has two problems,

a) Failed to emit module

and when removing the offending code

b) error XS0176 Member cannot be accessed with an instance reference; qualify it with a type name instead

// core dialect, allowdot- (disabled)
ENUM MyEnum 
	MEMBER m1
	MEMBER m2
END ENUM


CLASS TestClass
	EXPORT myEnum AS INT
	EXPORT AnotherTest AS AnotherTest

	CLASS NestedClass
		METHOD Test() AS VOID
			// failed to emit module
			MyEnum.m1:ToString()
			LOCAL e AS MyEnum
			IF e == MyEnum.m1
			END IF
			
			// error XS0176: Member 'AnotherTest.StaticMethod()' cannot be accessed with an instance reference; qualify it with a type name instead
			AnotherTest.StaticMethod()
	END CLASS
	
END CLASS

CLASS AnotherTest
	STATIC METHOD StaticMethod() AS VOID
END CLASS

I will add the tests in the test suite

[cpyrgas]

Final report, this also causes a failed to emit module error, for the code inside the static method. All above reports are combined in a single file in C917 in the test suite

// core dialect, allowdot- (disabled)
CLASS ThirdTest
	PROPERTY System AS LOGIC AUTO
		
	CONSTRUCTOR()
		System.Diagnostics.Debug.WriteLine( "Hi" ) // OK
	METHOD Test1() AS VOID
		System.Diagnostics.Debug.WriteLine( "Hi" ) // OK
	RETURN
	STATIC METHOD Test2() AS VOID
		System.Diagnostics.Debug.WriteLine( "Hi" ) // Failed to emit module
	RETURN
END CLASS

[cpyrgas]

Nik, any luck with this?

[nvkokkalis]

The "fail to emit" issues and the first case of XS0176 should be fixed now.

[nvkokkalis]

OK, the rest of the cases should be fixed now too.

[cpyrgas]

That's great! Robert, can you force a generation of the compiler binaries so I can test this?

[cpyrgas]

Good job Nik, it works great now in all cases, except one (special case):

In VO, it was possible to access members of (VO)structures only with the dot operator, in X# (and I think also in vulcan) we additionally allowed the colon.

So only for this special case, the compiler needs to always allow using the dot (and the colon), no matter the state of /allowdot

(all code ported from VO uses the dot)

VOSTRUCT _VOSTRUCT
MEMBER n AS INT
MEMBER m AS INT

FUNCTION Start() AS VOID
LOCAL vas AS _VOSTRUCT
LOCAL vis IS _VOSTRUCT

vas := (_VOSTRUCT PTR)MemAlloc(SizeOf(_VOSTRUCT))

vis:n := 123 // OK
? vis:n
vis.n := 123 // error XS0118: 'vis' is a variable but is used like a type
? vis.n

vas:n := 123 // OK
? vas:n
vas.n := 123 // error XS0118: 'vis' is a variable but is used like a type
? vas.n

[RobertvanderHulst]

I have committed this and triggered the build action

[cpyrgas]

It's almost perfect now, except for one case, test C689 fails:

error XS1061: 'System.DateTime' does not contain a definition for 'yyyy' and no accessible extension method 'yyyy' accepting a first argument of type 'System.DateTime' could be found
error XS0103: The name 'MM' does not exist in the current context
error XS0103: The name 'dd' does not exist in the current context
error XS1061: 'System.DateTime' does not contain a definition for 'yyyy' and no accessible extension method 'yyyy' accepting a first argument of type 'System.DateTime' could be found


#pragma options (allowdot, off)
PROCEDURE TestAllowDotOff()
	LOCAL s AS STRING

	LOCAL n AS INT
	n := 123
	s := i"{n:0000}" //ok
	? s
	
	LOCAL dData AS DateTime
	dData := DateTime{2019,11,09}
	s := i"{dData:yyyy-MM-dd}" // error XS1061, XS0103
	? s
	xAssert(s == "2019-11-09")
	s := i"{dData:yyyy\/MM\/dd}"  // error XS1061
	xAssert(s == "2019/11/09")
RETURN

[cpyrgas]

Oh, there's one more problem, with VOSTRUCT in GLOBAL:

// error XS0246: The type or namespace name 'gis' could not be found 

#pragma options (allowdot, off)
VOSTRUCT _VOSTRUCT
MEMBER n AS INT
MEMBER m AS INT

GLOBAL gis IS _VOSTRUCT

FUNCTION Start() AS VOID
gis:m := 2 // ok
gis.n := 3 // error XS0246
? gis.m * gis:n // error XS0246

[cpyrgas]

Confirmed fixed

[cpyrgas]

I had thought about adding this as a new ticket, but better include it in this one. There are naming conflicts now:

/*
error XS0120: An object reference is required for the non-static field, method, or property 'testStruc.n'
error XS0117: 'VO.Bitmap' does not contain a definition for 'm'
*/

USING VO

CLASS VO.Bitmap
END CLASS

VOSTRUCT testStruc
	MEMBER n AS INT
	MEMBER m AS INT

#pragma options (allowdot, off)
FUNCTION Start( ) AS VOID
	LOCAL testStruc IS testStruc
	testStruc.n := 123 // error XS0120
	? testStruc.n // error XS0120
	
	LOCAL bitmap IS testStruc
	bitmap.m := 456 // error XS0117
	? bitmap.m // error XS0117
RETURN

[cpyrgas]

You could argue that setting the /allowdot option to enabled fixes this (although the naming conflict does not sound right in the first place), but then, when enabling the /allowdot option, the original problem reappears again:

// this compiles without errors only when /allowdot is disabled
class TestClass
property System as logic auto
constructor()
	System.Diagnostics.Debug.WriteLine( "Hi" )
end class