Allow for null XmlSerialziers when loading pre-gen from mappings. #73827
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #68659
When nullable annotations were added to System.Xml, the return type of
XmlSerializer.FromMappings()was not annotated. Mistakenly. While I believe it is true that we generate an XmlSerializer for every mapping passed into the method in the runtime-generated-serializer case, when drawing serializers from a pre-generated serializer assembly... if the assembly doesn't have a matching serializer for the mapping, we don't generate one. Ideally the pre-gen assembly and list of mappings in use are under the control of the same project/team/application or whatever, so there is a serializer for every mapping. But "ideally" isn't always the case. And in this code, the mappings array and the pregenerated serializer assembly are in theory from different sources and may not match up. And when that happens, we need to return a null entry in the serializer array - because there is the expectation that positions in the returned serializer array match up with the corresponding position in the mapping array passed in.That's all a long-winded way of saying that we might return null serializer entries in the pre-gen case. That's has always been the case and it is expected. The nullable notation missed that, and as a result, we missed this potential null-ref.