ID:2389955
 
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.
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.
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?
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.
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.
I am not able to reproduce this using your same code. Can you shoot me a test project?
Lummox JR changed status to 'Unverified'
Here is a test project.

Just click the verbs and notice the output.
Lummox JR changed status to 'Verified'
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.
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.
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