Fix NRT annotations on XmlProcessingInstruction

[SteveDunn]

Description

XmlProcessingInstruction is not annotated correctly. The implementation of Name explicitly accomodates a null target, and its Target is annotated as nullable. The Value property, which just returns _data, is annotated as [AllowNull] but just !s away a null value that's stored, so it can actually return null. Please see this PR comment for more context.

Reproduction Steps

No particular reproduction steps

Expected behavior

No specific behavioural changes should occur, this is just a compile time issue.

Actual behavior

No specific behavioural changes should occur, this is just a compile time issue.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-xml
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

XmlProcessingInstruction is not annotated correctly? The implementation of Name explicitly accomodates a null target, and its Target is annotated as nullable. The Value property, which just returns _data, is annotated as [AllowNull] but just !s away a null value that's stored, so it can actually return null. Please see this PR comment for more context.

Reproduction Steps

No particular reproduction steps

Expected behavior

No specific behavioural changes should occur, this is just a compile time issue.

Actual behavior

No specific behavioural changes should occur, this is just a compile time issue.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	SteveDunn
Assignees:	-
Labels:	area-System.Xml, untriaged
Milestone:	-

[krwq]

I had to refer spec to figure out correct annotations since current implementation doesn't make it in any way easy.

Per https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-pi

• target cannot be null - current implementation will throw when it encounters null target: I'm changing the behavior to throw and making it explicitly non-nullable
• data - per spec this is optional although for current implementation there is no distinction between empty and null and current implementation return empty string when data is not provided: I'm changing the behavior that all getters for Data/Value (and whatever else it's called) are non-nullable and all setters are nullable - null will always translate to empty string since per spec it's equivalent and will make it most consistent with current implementation