[Debug] throw deprecation when @return void is found

[nicolas-grekas]

The DebugClassLoader does lightweight static analysis at autoload time already and triggers deprecations when some annotations in a docblock hint it to do so.

When this class finds a method that doesn't have void as return type but whose parent has the @return void annotation, we should trigger a deprecation - unless it also has the same annotation.
The should hint ppl to add the void return type immediately in their code and be ready for next-major of the parent class, which will be able to smoothly turn the annotation to a real void declaration.

ping @fancyweb @GuilhemN since you contributed similar rules in the past.

[theofidry]

@nicolas-grekas wouldn't that be both tricky & incomplete since traditionally:

function foo();

implies:

function foo(): void;

Whereas if something was returned, we have:

/**
 * @return mixed
 */
function foo();

?

[nicolas-grekas]

function foo(); implies: function foo(): void;

That's maybe conceptually correct - you can't rely on anything else - but that's technically inaccurate - you can return anything with such a signature.

That's why it works - we only care about technicalities here.

[theofidry]

Yes, but my point was more about he fact that there is almost no usage of “@return void” in the wild, well at least in my experience. I suppose it may be different in the Symfony codebase

…

On Sat 9 Feb 2019 at 10:56, Nicolas Grekas ***@***.***> wrote: function foo(); *implies*: function foo(): void; That's maybe conceptually correct - you can't *rely* on anything else - but that's technically inaccurate - you *can* return anything with such a signature. That's why it works - we only care about technicalities here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE76gXAJM348HpVFXROgvTzDWKZJ_kyVks5vLptmgaJpZM4aybS_> .

[nicolas-grekas]

From the fabbot failure on #30124 we can even say there are none :) Which is nice actually as ppl can start using it and express backward-compatible semantics for void.

[fancyweb]

@nicolas-grekas Why should we do it only for the void return type ?

[nicolas-grekas]

Good question :)
We can do it for other return types IF they can be expressed as real return type indeed.

[fancyweb]

I'm going to work on it.