…ror during denormalization (lyrixx)This PR was merged into the 5.4 branch.Discussion----------[Serializer] Add support for collecting type error during denormalization| Q             | A| ------------- | ---| Branch?       | 5.4| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Tickets       |Fixsymfony#27824,Fixsymfony#42236,Fixsymfony#38472,Fixsymfony#37419Fixsymfony#38968| License       | MIT| Doc PR        |---There is something that I don't like about the (de)Serializer. It's about the way it deals with typed properties.As soon as you add a type to a property, the API can return 500.Let's consider the following code:```phpclass MyDto{    public string $string;    public int $int;    public float $float;    public bool $bool;    public \DateTime $dateTime;    public \DateTimeImmutable $dateTimeImmutable;    public \DateTimeZone $dateTimeZone;    public \SplFileInfo $splFileInfo;    public Uuid $uuid;    public array $array;    /** `@var` MyDto[] */    public array $collection;}```and the following JSON:```json{"string": null,"int": null,"float": null,"bool": null,"dateTime": null,"dateTimeImmutable": null,"dateTimeZone": null,"splFileInfo": null,"uuid": null,"array": null,"collection": [{"string": "string"},{"string": null}]}```**By default**, I got a 500:![image](https://user-images.githubusercontent.com/408368/129211588-0ce9064e-171d-42f2-89ac-b126fc3f9eab.png)It's the same with the prod environment. This is far from perfect when you try to make a public API :/ATM, the only solution, is to remove all typehints and add assertions (validator component). With that, the public API is nice, but the internal PHP is not so good (PHP 7.4+ FTW!)In APIP, they have support for transforming to [something](https://github.com/api-platform/core/blob/53837eee3ebdea861ffc1c9c7f052eecca114757/src/Core/Serializer/AbstractItemNormalizer.php#L233-L237) they can handle gracefully. But the deserialization stop on the first error (so the end user must fix the error, try again, fix the second error, try again etc.). And the raw exception message is leaked to the end user. So the API can return something like  `The type of the "string" attribute for class "App\Dto\MyDto" must be one of "string" ("null" given).`. Really not cool :/So ATM, building a nice public API is not cool.That's why I propose this PR that address all issues reported* be able to collect all error* with their property path associated* don't leak anymore internalIn order to not break the BC, I had to use some fancy code to make it work 🐒With the following code, I'm able to collect all errors, transform them in `ConstraintViolationList` and render them properly, as expected.![image](https://user-images.githubusercontent.com/408368/129215560-b0254a4e-fec7-4422-bee0-95cf9f9eda6c.png)```php    #[Route('/api', methods:['POST'])]    public function apiPost(SerializerInterface $serializer, Request $request): Response    {        $context = ['not_normalizable_value_exceptions' => []];        $exceptions = &$context['not_normalizable_value_exceptions'];        $dto = $serializer->deserialize($request->getContent(), MyDto::class, 'json', $context);        if ($exceptions) {            $violations = new ConstraintViolationList();            /** `@var` NotNormalizableValueException */            foreach ($exceptions as $exception) {                $message = sprintf('The type must be one of "%s" ("%s" given).', implode(', ', $exception->getExpectedTypes()), $exception->getCurrentType());                $parameters = [];                if ($exception->canUseMessageForUser()) {                    $parameters['hint'] = $exception->getMessage();                }                $violations->add(new ConstraintViolation($message, '', $parameters, null, $exception->getPath(), null));            };            return $this->json($violations, 400);        }        return $this->json($dto);    }```If this PR got accepted, the above code could be transferred to APIP to handle correctly the deserializationCommits-------ebe6551 [Serializer] Add support for collecting type error during denormalization

…torArgumentsException (BafS)This PR was squashed before being merged into the 5.4 branch.Discussion----------[Serializer] Save missing arguments in MissingConstructorArgumentsException| Q             | A| ------------- | ---| Branch?       | 6.0 (but it could maybe be 5.4?)| Bug fix?      | no| New feature?  | not really| Deprecations? | no| Tickets       | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->| License       | MIT| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->It's currently not possible to get the information about which constructor argument is missing (except by doing regex in the exception message string). Having this information is useful when we want to have an input transformer without the need to set every fields to nullable.For example with this flow: `[request payload] -> [normalizer/unserializer] -> [dto] -> [validation]`, each field must be nullable to not have exception during the normalization and then we still need to validate, instead we could catch `MissingConstructorArgumentsException`, handle it and make a nice http exception.Edit: related to#42502Commits-------903a94a [Serializer] Save missing arguments in MissingConstructorArgumentsException

…hat exception it throws (Nyholm)This PR was merged into the 5.4 branch.Discussion----------[Serializer] Make sure Serializer::denormalize() shows what exception it throws| Q             | A| ------------- | ---| Branch?       | 5.4| Bug fix?      | no| New feature?  | no| Deprecations? | no| Issues        | no| License       | MITThis was missing from#42502. We have no contract that explains that this exceptions should be thrown.With this addition, we technically make this a "sometimes" feature of the Serializer class.Commits-------bca846b Make sure Serializer::denormalize have show what exception it throws