DM confuses top-level vars with the vars of instances if they are not typecasted.

ID:2389955
 
Aug 6 2018, 10:36 am (Edited on Aug 7 2018, 1:16 pm)
Resolved
From the primordial swamp: a reference like foo:bar, where bar is both an object var and a global var and foo is an untyped local var, was misread by the compiler as global.bar.
BYOND Version:512.1444
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 67.0.3396.87
Applies to:Dream Maker
Status: Resolved (512.1445)
This issue has been resolved.
Descriptive Problem Summary:
DM confuses top-level vars with the vars of instances if they are not typecasted.

Code Snippet (if applicable) to Reproduce Problem:
var/myvar = "I'm a top-level var."

obj/var/myvar = "I'm a var."


proc/testvar()
    var/o = new /obj

    if(o:myvar == myvar)
        world << "Something is very wrong here!"

mob/verb/test()
    testvar()


Expected Results:
Nothing happens, because obj.myvar != global.myvar.

Actual Results:
The code above does output the message, which should never happen.
Also, Dream Maker complains: warning: o: variable defined but not used

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Edit: There were none that I could find.

Workarounds:
Use typecasting:
var/myvar = "I'm a top-level var."

obj/var/myvar = "I'm a var."


proc/testvar()
    var/obj/o = new /obj

    if(o:myvar == myvar)
        world << "Something is very wrong here!"

mob/verb/test()
    testvar()

In this case, there is no output, as you would expect.
Aug 7 2018, 11:24 am
Sorry, for not testing before, but this is NOT a beta bug, so it shouldn't have been moved there.

The following test case shows the same output as far back as 354.913, the earliest available version:
var/myvar = "I'm a top-level var."

obj/var/myvar = "I'm a var."


proc/testvar()
    var/o = new /obj

    if(o:myvar == myvar)
        world << "Something is very wrong here!"

mob/verb/test()
    testvar()

It's strange because I thought it was working before. I guess not.
Aug 7 2018, 12:13 pm
Worth noting that according to my testing, the issue here is the comparison. Reading the variables works as expected, but not comparing them. Compiler optimization issue, maybe?
Aug 7 2018, 12:53 pm
I moved this to Beta Bugs because your original example had o:vars and vars, and global vars weren't a thing before 512. Your example made it look like this was an issue with the vars list, not with individual vars. That's a huge distinction.

I'll move this back.
Aug 7 2018, 1:13 pm
That's my bad. I replaced the old examples to avoid confusion. The vars list just happened to be the most simple test case, but wasn't the best in that context.
Aug 7 2018, 1:26 pm
I am not able to reproduce this using your same code. Can you shoot me a test project?
Aug 7 2018, 1:26 pm
Lummox JR changed status to 'Unverified'
Aug 7 2018, 1:55 pm
Here is a test project.

Just click the verbs and notice the output.
Aug 7 2018, 2:57 pm
Lummox JR changed status to 'Verified'
Aug 7 2018, 3:28 pm
Okay, I see what I did wrong. Looks like I copied from your workaround rather than the original by mistake.

Good gads is this one tricky. The problem comes in a routine called EvalVarPath() in the compiler's guts, where it's trying to determine a var's type. Because of the lack of type it's calling the global root its parent, which wouldn't be an issue if not for the fact that there's a global var of the same name.

I've messed with this routine before for other purposes, but not for a case like this. This is a really weird one.

The main thing is, it looks like I have to teach the code that var1:var2 is never a case for looking up global var2.
Aug 7 2018, 9:19 pm
Lummox JR resolved issue with message:
From the primordial swamp: a reference like foo:bar, where bar is both an object var and a global var and foo is an untyped local var, was misread by the compiler as global.bar.
Aug 8 2018, 10:50 am
And apparently what I said above is only true for the vars list, for some reason
Doesn't really matter since it's fixed now