`#[Override]` being a fatal E_COMPILE_ERROR leads to bad usability/update hell

[kkmuffme]

Description

The following code:
https://3v4l.org/5bkAg#v8.5.1

<?php

class A {
    public function run_new() {}
}

class B extends A {
    #[Override]
    public function run() {}
}

Resulted in this output:

Fatal error: B::run() has #[\Override] attribute, but no matching parent method exists

But I expected this output instead:

Warning: B::run() has #[\Override] attribute, but no matching parent method exists

A and B are from 2 different libraries/packages/plugins
"A" cannot know that "B" used #[Override] so they just removed the method in a new version. Now if "A" is updated by the user (be it via composer where the common ^1.2 syntax is used, or be it a WordPress/Drupal/... plugin) the user now has a broken application.
Even if "B" has a new version that has the #[Override] attribute removed, it would be necessary to first update "B" before updating "A" and to actually know about this issue in advance before updating.
Since E_COMPILE_ERROR is fatal, any update commands or UI won't work either - also composer.lock is useless, since it already contains the updated "A". Which means that you need to completely reinstall it (removing composer.lock and vendor), which results in likely different versions of other packages than you had installed before unless your composer.json is extremely tightly versioned and updated and therefore other issues.
If it's a CMS plugin, you essentially are required to manually either downgrade "A" (if thats even possible) or manually via FTP update "B".

Since there's no real "harm" in there being no matching parent method/property and since other attributes like #[NoDiscard] also result in a warning instead of a fatal, I think the E_COMPILE_ERROR of the Override attribute should be changed - retroactively for PHP 8.3 + 8.4 too, as they are most likely affected by this, being older versions and running code that will have updates available - to a warning only.

PHP Version

8.3+

Operating System

No response

[jordikroon]

I get why you expect or prefer a warning, but the fatal error is intentional and matches the RFC.

#[Override] is a promise from the child class: "I am overriding a method that exists in the parent." If that parent method no longer exists, something is wrong and PHP should stop immediately. If this were only a warning, the code would keep running while the intended override is not happening anymore, which can lead to subtle bugs that are much harder to notice and debug.

[kkmuffme]

which can lead to subtle bugs that are much harder to notice and debug

In how far? It will still emit an E_WARNING

#[Override] is a promise from the child class: "I am overriding a method that exists in the parent." If that parent method no longer exists, something is wrong

Exactly, just like with NoDiscard - but its not a fatal error, but a warning. Using this reasoning, it can be 1:1 applied to NoDiscard.

and PHP should stop immediately

Why?

---

Just accidentally stumbled upon https://wiki.php.net/rfc/delayedtargetvalidation_attribute which is part of PHP 8.5 and seems to exactly fix the issue at hand. Will check that out and possibly close or update the issue #[DelayedTargetValidation] explicitly doesn't work for this Override case

[kkmuffme]

Another issue is static analysis (phpstan, psalm), which unlike its name suggests isn't that "static", but generally uses the composer or a custom autoloader (for Reflection).
Since this will result in a fatal E_COMPILE_ERROR they can't analyze but will fail with a fatal in cases where a class extends a stubbed class. This is a common occurrence when providing compatibility support for various packages or PHP extensions - which often are mutually exclusive (when package/PHP extension X is installed, Y cannot be used at the same time, however my code should work with either/or) and can therefore not be loaded at the same time.

[iluuu1994]

This works as proposed. Please use the mailing list for discussion of behavioral changes.

[TimWolla]

"A" cannot know that "B" used #[Override] so they just removed the method in a new version.

Removing a non-private method is a breaking change both with and without #[\Override], since folks might call this method. #[\Override] just makes the breaking change easier to detect for the case of overriding a method or implementing an interface method.

and since other attributes like #[NoDiscard] also result in a warning instead of a fatal,

The difference between #[\Override] and #[\NoDiscard] is that for #[\Override] the only one who is affected by the behavior of the attribute is the one who is applying the attribute and who thus is in full control. #[\NoDiscard] however affects the users of the function or method having the attribute.