call(Object,Object::ProcName()() does not run correctly with parent procs

ID:2867302
 
Apr 28 2023, 9:09 am
BYOND Version:515.1605
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 112.0.0.0
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Hope this doesn't count as a duplicate thread. I didn't want to clutter a thread with two sets of issues, even if they are similar.

Descriptive Problem Summary:

call(Object,Object::ProcName()() does not run the src's ProcName if the call is inside the child's proc definition, and also runs the first child proc twice, and the child of the child's proc once.

Code Snippet (if applicable) to Reproduce Problem:
world
    fps = 25      // 25 frames per second
    icon_size = 32    // 32x32 icon size by default

    view = 6     // show up to 6 tiles outward from center (13x13 view)

    mob = /mob/living/advanced

mob
    step_size = 8

obj
    step_size = 8


/mob/New(var/desired_loc)
    . = ..()
    world.log << "New: You are a [src.type]."
    cook()

/mob/proc/cook()
    world.log << "Cook's type (PART A): [src.type]."

/mob/living/cook()
    . = ..()
    world.log << "Cook's type (PART B): [src.type]."
    call(src,src::potato())()

/mob/living/advanced/cook()
    . = ..()
    world.log << "Cook's type (PART C): [src.type]."

/mob/proc/potato()
    world.log << "First Potato"

/mob/living/potato()
    . = ..()
    world.log << "Second Potato"

/mob/living/advanced/potato()
    . = ..()
    world.log << "Third Potato"


Expected Results:
Welcome BYOND! (5.0 Beta Version 515.1605)
Logging in...connected
Logged in as BurgerBB.
Connecting to file://testcase.dmb...connected
New: You are a /mob/living/advanced.
Cook's type (PART A): /mob/living/advanced.
Cook's type (PART B): /mob/living/advanced.
First Potato
Second Potato
Third Potato
Cook's type (PART C): /mob/living/advanced.

Actual Results:
Welcome BYOND! (5.0 Beta Version 515.1605)
Logging in...connected
Logged in as BurgerBB.
Connecting to file://testcase.dmb...connected
New: You are a /mob/living/advanced.
Cook's type (PART A): /mob/living/advanced.
Cook's type (PART B): /mob/living/advanced.
First Potato
Second Potato
Second Potato
Cook's type (PART C): /mob/living/advanced.

Does the problem occur:
Every time? Or how often? Every time.
In other games? In other games.
In other user accounts? Can't test
On other computers? Can't test.

When does the problem NOT occur?
When call(src,src::potato())() is inserted into every instance of cook() and the parent proc not run.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? In 514 with old call()() code.

Workarounds:
Defining call(src,src::potato())() in every cook() proc.

Apr 28 2023, 9:53 am
Except for running the mob/living/cook() proc twice, which shouldn't be happening, I'm not sure this is a bug. Resolution of proc refs isn't meant to be done at runtime, and I think that's where things are getting confused. I'll need to look into this deeper, however.

What I can tell you for sure is that this is the wrong way to handle the call(). I suggest wrapping src::procname() in the nameof() compiler operator. When you use call() with a direct proc ref, the expectation is that you're trying to call a very specific version of the proc and not the one that's appropriate to src.
Apr 28 2023, 10:43 am
In response to Lummox JR
This works, thank you!
Apr 29 2023, 11:25 pm
In response to Lummox JR
Lummox JR wrote:
... I'm not sure this is a bug. Resolution of proc refs isn't meant to be done at runtime, and I think that's where things are getting confused. ...

I don't want to intrude but uh, we rely on runtime proc path resolution for our debugging tools, and it would be a major user (admins) and dev hit for it to not work, at least if I'm reading this right.
May 1 2023, 10:08 am
In response to LemonInTheDark
I doubt we're talking about the same thing in this case.

Burger was relying on old behavior where even though .proc/Something was a proc reference, it basically got turned into a by-name call at runtime. 515 introduced a breaking change since you can call a specific proc reference instead of it being by name, so anyone wanting the by-name behavior (which is almost all of the time) needs to use the name of the proc instead. Hence the nameof() and __PROC__ pseudomacros that were added in 515.