Annotate System.Private.DataContractSerialization

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes

[tlakollo]

Reenable the AOT analyzer in System.Private.DataContractSerialization

Related to: #73337

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[MichalStrehovsky]

Thanks!

[StephenMolloy]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

[LakshanF]

I don't have a firm grasp on what RequiresDynamicCode is attempting to accomplish here. It obviously looks quite similar to and even mostly tags the same places as RequiresUnreferencedCode - so I assume its a similar idea but for IL/code we generate instead of code we reflect. It looks mostly like attributes going in, so I don't have a problem here so long as you guys are comfortable that you've got the right set of things attributed.

Yes, both attributes are related but RequiresUnreferencedCode (RUC) is used in trimming, where a static analysis of the full dependency closure by the compiler cannot determine correctness and warns the developer. Use of unbounded reflection is one such area where the compiler has problems. RequiresDynamicCode (RDC) is used to create NativeAOTapplications and the attribute is used to warn the developer that runtime code generation is likely used by the application which is not supported in that deployment model. NativeAOT relies heavily on trimming and the RUC warnings as well and there are some overlaps (MakeGenericType for example, but for reasons described above)

[LakshanF]

The tests shown as failing seems to be passing - for example, at least the test here, and the failure seems to be related to a cloud issue where upload test run result XML is failing.

[tlakollo]

In the PR there are a couple of cases in which we suppress because the RuntimeFeature.IsDynamicCodeSupported flag is used, meaning the code has a way to execute the code when published using a tool that doesn't support DynamicCode. On the other hand RUC sometimes uses DynamicallyAccessedMembers to keep members around and making things safe which sometimes is not enough for DynamicCode purposes. The PR also annotates things that directly generate code dynamically (example) and that piece of code is completely safe for Trimming purposes