Setting a variable to type::some_var doesn't work

ID:2942885
 
Sep 1, 6:49 am
BYOND Version:515
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 129.0
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Setting a variable to type::some_var doesn't work in the latest version of 515, whereas in 515.1635 it did.
parent_type::some_var works fine.

Numbered Steps to Reproduce Problem:
1. Try to define a variable's value as type::some_other_var.
2. Compilation error.

Code Snippet (if applicable) to Reproduce Problem:
/datum
 var/my_thing = "waaa"
/datum/foo
 var/my_other_thing = type::my_thing
/world/New()
 world.log << json_encode(/datum/foo::my_other_thing)


Expected Results:
Outputs "waaa".

Actual Results:
error, line 6: /datum/foo::my_other_thing: compile failed (possible infinite cross-reference loop)
error, line 4: type::my_thing: compile failed (possible infinite cross-reference loop)


Does the problem occur:
Every time? Or how often? Every time in the latest version of 515.
In other games? Yes.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?
On BYOND 515.1635.

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.)
I haven't tested it myself, but others report that 515.1635 and earlier work just fine.

Workarounds:
Use 515.1635 or earlier, or paste the type directly instead of being lazy like me. I tried using __TYPE__ instead of type, and that just gave a different error message. In circumstances where it can be used instead, parent_type::some_var works fine.
Sep 1, 7:33 am
Also, even in 515.1635, repeating it doesn't work. /obj/thing::material::color won't get the compile-time value of /obj/thing::material's color variable. All of this should be able to be const-evaluated at compiletime, but the compiler complains that it "expected a constant expression".
Sep 1, 8:36 am (Edited on Sep 1, 9:01 am)
I come with yet another test case for something broken with foo::bar:
/obj/item/var/paint_color = null
/obj/item/banner
 paint_color = "#ffffff"
 color = type::paint_color

/obj/item/banner/green
 paint_color = "#00ff00"
 color = type::paint_color

This works fine in 515.1635. However:
/obj/item/var/paint_color = null
/obj/item/banner
 paint_color = "#ffffff"
 color = type::paint_color

/obj/item/banner/green
 paint_color = "#00ff00"
 color = type::paint_color

/obj/structure/banner_frame/wall/ebony/green
    color = /obj/item/banner/green::color // Mapping preview colour.

The second code snippet fails to compile in 515.1635 with test.dm:8:error: ::: bad var or proc() after :: operator. Notably, it compiles fine in 515.1623, and fails again in 515.1624.

The actual project I'm working on has 2 similar cases that still fail in 515.1623 and which I still haven't found solutions for. Those cases are as simple as having color = /decl/material/solid/organic/plantmatter/grass/dry::color on a type, in this case /obj/item/banner/woven, but I don't have an isolated test case prepared for it. In 515.1620, however, the actual project builds fine. To make matters worse, this case actually works fine in the latest build of 515, because it doesn't use type::foo at all!

EDIT: Here's a test-case for that third issue, though I think it's resolved by 515.1624. It's still good to have an isolated test to make sure new fixes don't cause yet another regression, so here:
/obj/item/var/paint_color = null
/decl/material/var/color = "#ffffff"
/decl/material/drygrass
 color = "#ffff00"

/obj/item/woven
 color = /decl/material/drygrass::color

/world/New()
    world.log << /obj/item/woven::color
    ..()
    shutdown()
Sep 1, 12:19 pm
I don't think this is a bug. A type referencing itself before it can resolve is simply something the compiler can't handle.
Sep 1, 8:18 pm
It did work at some point in the past, however, and it has a clear use-case in my opinion. I'm not expecting cases with circular references to work, but it seems StrongDMM and other tools can resolve these just fine. As long as it's a linear chain of dependencies it should be possible, and given that replacing type with the literal typepath works, it really should work fine.

To be clear, I'm not asking for it to be automatically re-defined on all subtypes. I want it specifically just as a shorthand for /current/typepath::foo.
Sep 7, 12:37 am (Edited on Sep 7, 11:15 am)
Issue is persisting in 515.1642 and does not even allow using literal typepath:
/mob
    var/proc_ref

/mob/proc/do_thing()
    return

/mob/test
    proc_ref = /mob/test::do_thing()

/mob/test/do_thing()
    return


Error:
...:error: /mob/test::do_thing:  compile failed (possible infinite cross-reference loop)


Changing
proc_ref = /mob/test::do_thing()

to
proc_ref = /mob::do_thing()

does not throw an error

Login to reply.