ID:2893141
 
Resolved
The warning for no parent call on ..() appeared incorrectly in cases where the proc's definition appeared later in the source.
BYOND Version:515.1617
Operating System:Windows 11 Home
Web Browser:Chrome 117.0.0.0
Applies to:Dream Maker
Status: Resolved (515.1618)

This issue has been resolved.
Descriptive Problem Summary:
the new Compiler "no_parent" warnings error on procedures with parent calls

Numbered Steps to Reproduce Problem:
Call parent on a procedure that is defined later in the code by a parent object. Compiler warning (but no changes to the code in runtime)

Code Snippet (if applicable) to Reproduce Problem:
mob
display_error()
..()
client << "we do things"

atom
verb
display_error()
set name = "do the thing"
set category = "debug"
CRASH("this also does things")


switching the atom/mob locations will cause no compiler errors to be displayed

Expected Results:
No warnings

Actual Results:
Compiler issues a warning to the display error verb, even though it has a functioning parent call

Does the problem occur:
Every time? Or how often?Yes
In other games?Yes
In other user accounts?Yes
On other computers?Yes

When does the problem NOT occur?
N/A

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.) Any version below 515.1617

Workarounds:
Define base objects and base object procedures before defining child class procedures

I'm confused about part of your report, because it sounds like you're suggesting that ..() not producing a warning in Stat() is a bug. It isn't; the lack of a warning there is intended behavior. The warning is only supposed to happen if there is no supercall, not if the supercall does nothing.

The verb override producing this warning is, however, a bug.
In response to Lummox JR
report updated, the stat stuff was just me misunderstanding the applications of the warning. q-q
Lummox JR resolved issue with message:
The warning for no parent call on ..() appeared incorrectly in cases where the proc's definition appeared later in the source.