Compiler allows using the dot for accessing instance members, even if /allowdot is not enabled

[cpyrgas]

In the following code, the compiler reports an error for n.ToString(), but not for the other two cases where using the dot operator for accessing instance members. The /allowdot compiler option is disabled

FUNCTION Start() AS VOID
LOCAL n AS INT
n.ToString() // error, correct
TestClass{}.ToString() // no error

CLASS TestClass
CONSTRUCTOR()
SELF.ToString() // no error
END CLASS

[RobertvanderHulst]

The diference is caused by the fact that n is an identifier and SELF is a keyword.
SELF can never be a typename. SUPER will show the same behavior.
However the behavior is inconsistent, so I'll try to change it.

[RobertvanderHulst]

I have checked and it is fairly complicated to prevent Roslyn from resolving the 2 other methods.
However I managed to intercept the "Diagnostic Pass" of the compiler and detect when you are accessing Instance members (fields, properties, methods) using the DOT (.) operator.
I will add a new compiler error (or should this be a warning):
error XS9112: You cannot access the instance member 'ToString' from the type 'object' with the DOT '.' operator.
The method call n.ToString() is handled by Roslyn already and results in the error
error XS0118: 'n' is a variable but is used like a type

What do you think of this?

[cpyrgas]

Robert,
I don't see a reason to mention the type name, the problem is accessing an instance member with the dot, period. So I think something like this is better:

error XS9112: You cannot access the instance member 'ToString' with the DOT '.' operator.

But please treat all this as low priority. It's just because myself, I hate using the dot for instance members, so when I saw some code from a customer and I noticed that it compiled with no errors although it contained that, I went into rage mode :). But most likely it will not be noticed by anybody else...

[RobertvanderHulst]

I have added the warning now, with the exception for VOSTRUCT types. These still allow the Dot.
Unfortunately, quite a lot of the tests contain this problem. I had to make changes to many of the tests to compile without errors.
Most likely, this is also going to annoy some of our users...
So should we really do this ?

[cpyrgas]

Robert, you mean many tests use the dot for accessing instance members? Very surprised to hear that! I think it does not make sense allowing this when /allowdot is disabled, and when someone wants to use it,they can simply enable the option, but owuld like to have a look at the failing tests (and with users' apps) to get a better idea.

I will not download the latest changes for now (so I can still see the previous version of the tests), please tell me when the new compiler (containing this change) is up, so I can give it a test.

[cpyrgas]

Robert, I only saw two compiler tests (and one runtime test) that were failing because of this, and both were your tests :) :) :)
I also tested with a couple millions lines of code form several customers, and the compiler complained in for one's code, in 5-6 places in total. All of them were clear errors in the code which were very easy to fix.

Personally I think it's a good fix, previous compiler behavior was clearly wrong and if anybody does not like the new behavior, the solutions is very easy, to enable the /allowdot option, this is why it was introduced for. If anybody complains I will explain myself, blame it on me :)