[release/8.0-rc1] Annotate System.Linq.Expressions with RequiresDynamicCode

[github-actions]

Backport of #90456 to release/8.0-rc1

/cc @agocke

Customer Impact

System.Linq.Expressions is a complicated area for Native AOT. Optimized compilation is not supported at all, but interpretation is. However, even with that, array creation and lifting of custom operators are not supported. This PR annotates array creation and disables custom operator lifting via a feature switch.

Notably, this does present a breaking change if you were relying on nullable lifting on custom operators in expression trees. There is no workaround in this situation. This feature is not supported in Native AOT.

Testing

Running existing unit tests and integration tests under Native AOT.

Risk

Low. This is an AOT-only change and mostly annotation-only.

[dotnet-issue-labeler]

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, 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.

[ghost]

Tagging subscribers to this area: @cston
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90456 to release/8.0-rc1

/cc @agocke

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.Linq.Expressions, new-api-needs-documentation
Milestone:	-

[ivanpovazan]

@agocke do these changes have any app size implications?
Additionally, can we run runtime-extra-platforms as well?

[agocke]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[carlossanlop]

The CI has failures. Is any of them related to this PR? If not, let me know so I can merge it (please don't click on "Update branch").

[agocke]

None of the failures seem related. I think this is good to merge.

@ivanpovazan This shouldn't have any material impact on size either way. It'll root Nullable<T> for the standard primitive types, but those were almost certainly rooted already.

[ivanpovazan]

Thank you for verifying runtime-extra-platforms runs!

@ivanpovazan This shouldn't have any material impact on size either way. It'll root Nullable<T> for the standard primitive types, but those were almost certainly rooted already.

Just for the reference: I did a quick check with a sample iOS application referencing System.Linq.Expressions and the binary size slightly goes up by ~50Kb with this change, which is ~0,4% size regression.

[eerhardt]

Thanks for getting this into .NET 8, @agocke.

[agocke]

@ivanpovazan That still seems negligible, but slightly more than I expected. Did you happen to confirm that the only difference is the types I mentioned?

[ivanpovazan]

@ivanpovazan That still seems negligible, but slightly more than I expected. Did you happen to confirm that the only difference is the types I mentioned?

I will try to do a diff with sizoscope and post it here, but probably tomorrow.

[ivanpovazan]

@agocke

• Here is the detailed size comparison:

HelloiOS + TestLinqExpressions	main	PR	diff (%)	diff (Kb)
Binary size on disk	12731024	12781160	0,39%	50,14

• Sizoscope diff (left - main, right - PR)

[agocke]

Hmm, weird, the sizoscope difference shows 8 KB, which is closer to what I expected, instead of 50. @MichalStrehovsky might have some insight when he gets back

[ivanpovazan]

I repeated the measurements with a console app built on osx-arm64 and the difference is 16Kb. Still not sure about the extra 8Kb on Mac, but the extra bytes noticed on iOS seem to come from the fact that the bundler we internally use does not fully strip symbols from the iOS application (stripping only local symbols) - this is not the case with Xamarin builds, which properly strip all the symbols.

That being said, sorry for the false alarm regarding iOS size bump.

[agocke]

No problem -- thanks for the info. I thought I fixed the linker size issue, I may still need to look into it more.

[MichalStrehovsky]

Hmm, weird, the sizoscope difference shows 8 KB, which is closer to what I expected, instead of 50. @MichalStrehovsky might have some insight when he gets back

Sizoscope/mstat doesn't capture everything in the executable but the size is usually proportional. You can get a closer view with IlcGenerateMapFile - the sizes of blobs that mstat cant account for might tell more.