This PR was merged into the 6.3 branch.

Discussion
----------

Add many missing PHPdoc return types

| Q             | A
| ------------- | ---
| Branch?       | 6.3
| Bug fix?      | no
| New feature?  | no
| Deprecations? | yes
| Tickets       | Ref #47551, continues #49342
| License       | MIT
| Doc PR        | -

This PR adds lots of ``@return`` PHPdoc that we missed in the 5.4 branch. These will produce new deprecation warnings, if applications override one of these methods. It will not break backwards compatibility.
Adding these PHPdoc in 6.3 already allow the community to test all these annotations for 6 months in stable version, before committing to adding them as PHP types in 7.0. This way, I hope we patch out any wrong type.

This PR is done using a slightly modified Psalter script, based on Psalm's type inference. See #49348 for the counter PR adding real PHP types to private, final or internal methods.

Commits
-------

e23d8be Add missing PHPdoc return types

This PR was merged into the 6.3 branch.

Discussion
----------

Add PHP types to private methods and functions

| Q             | A
| ------------- | ---
| Branch?       | 6.3
| Bug fix?      | no
| New feature?  | no
| Deprecations? | yes
| Tickets       | Ref #47551, continues #49342
| License       | MIT
| Doc PR        | -

This PR adds real PHP types to private, internal or final (excluding ``@final``) methods based on Psalm's type inference. Many more return types are missing still, but let's do them in other contributions.

This change can result in BC breaks in multiple ways, so we should carefully review the changes:

* A method may wrongly be considered "safe" by Psalter. If the method is unsafe (e.g. ``@final``, but not yet real `final`), we should instead add a PHPdoc return type (see #49349)
* Psalm may not infer the correct set of return types. If an unexpected type is returned, this will result in a PHP error.

Commits
-------

384c9a6 Add PHP types to private methods and functions

…(wouterj)

This PR was merged into the 5.4 branch.

Discussion
----------

[ErrorHandler] Do not patch return statements in closures

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

The type patcher script also fixes some return statements automatically to deal with void/null differences. However, the script is a bit too eager and also patches return statements of closures inside methods:

```php
public function something(): void
{
    $someHandler = function (): ?string {
        if (...) {
            return null;
        }
    };
}
```

Statements like this were patched to `return;`, causing a PHP fatal error.

Note: I didn't find any test for the return statement patching, so I also didn't write one for this bug. However, this bug is discovered by our own CI in #49342, so I would say we've covered the fix :)

Commits
-------

1779ee1 [ErrorHandler] Do not patch return statements in closures

This PR was merged into the 6.3 branch.

Discussion
----------

Add void (PHPdoc) return types

| Q             | A
| ------------- | ---
| Branch?       | 6.3
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | Ref #47551, continues #49342
| License       | MIT
| Doc PR        | -

This introduces lots of void return types to the codebase, following our policy:

* Adding ``@return` void` to any methods that return void is OK
* Adding `void` PHP return type is only OK if the method is internal, private or final (excluding ``@final``).

The changes in this PR are automated through a modified Psalter script. We should particularly review if ``@final`` classes/methods didn't get real PHP void return types, as this is a BC break.

Commits
-------

508ed81 Add void return types