Remove LINQ expression dependencies on NativeAOT

[Sergio0694]

This PR attempts to fix the IL3050 warnings in CsWinRT due to System.Linq.Expressions being pulled in. The goal is to just remove that dependency entirely when on NativeAOT, and allow the linker to correctly trim all of that code, which should also improve the binary size a bit more. There were a few issues preventing this from happening:

• Some checks for NativeAOT (via RuntimeFeature) were using unsupported patterns (see here)
• Some paths were unconditionally relying on LINQ expressions (eg. Nullable<T>)

This PR fixes both of those issues for all occurrences.

[dongle-the-gadget]

Seems like we are missing some types in GetValueDelegateForFunctionPointer?

• Point
• Size
• Rect
• Array types

[Sergio0694]

I just copied those from what was being registered in Projections.cctor. How come those weren't there? 🤔
As for array types... Why would those ever be in a Nullable<T> instance? Isn't IReference<T> just WinRT's "boxed" type?

[dongle-the-gadget]

IReference<T> can also store arrays.

[Sergio0694]

Can confirm that this fully removes the IL3050 warning from LINQ expressions when publishing! 🎉

Removing the assembly entirely is handled by #1435.

[Sergio0694]

Worth noting, this also saves ~128 KB!

[manodasanW]

So because of this, I feel like most of the types listed here won't come to this code path. Do you think having some specific nullable optimizations for each type is better or do you think have a generic version that handles all here is better? The main difference I see is with the former, we can list them as UnManagedCallersOnly whereas here we would need to do GetfunctionPointerForDelegate. Or should we keep both as is, and have this as a fallback in case that code path wasn't used?

[Sergio0694]

Oh, that's interesting, I didn't notice that. To clarify, all changes in this PR were solely driven by trying to fix all AOT warnings and allow all of that LINQ expression code to be trimmed out, basically I did the minimum amount of changes to satisfy that. I'm still seeing generic instantiations for all of these types, for instance:

So I'm inclined to say keeping both code paths can't hurt, and it might still help with trimming since it would make those generic instantiations get the specialized paths (even though we're not 100% sure they're actually executed at runtime). I would say perhaps let's just keep this for now and then we can potentially look into removing code once we've double checked that it is never in fact used anywhere, and also that it doesn't regress trimming? 🤔

What do you think?

"Do you think having some specific nullable optimizations for each type is better or do you think have a generic version that handles all here is better?"

Mmh good question. I can't say I have an exact answer here. It also depends on whether we'll be able to fully eliminate all other generic instantiations. If not, I wonder whether the additional code size and complexity is worth it. In theory there shouldn't be much overhead from just that single proxy delegate. But this is also something we could always revisit later, not a big deal I think either way.

[manodasanW]

Sounds good, we can keep both for now.

[manodasanW]

Note that in your sceenshot, that is all BoxedIReferenceArrayImpl which is different from BoxedIReferenceImpl. I know we have worked to do with arrays possibly.

[Sergio0694]

Oh sorry, looked at the wrong line 😅
Still seeing some instantiations from the correct type too, though not for primitive types:

So it seems they're still "duplicate", but with less potentially unnecessary instantiations?

[Sergio0694]

The type with a single type parameter does seem to only have one instantiation 🤔

[manodasanW]

For the first set, those come from here. I wasn't sure if I wanted to create specializations for each one so I had created a BoxedValueIreferenceImpl that takes both the type and the ABI type as generics so it was AOT compatible and had implemented it that way. With your changes, there might be opportunity in a future PR to make it again use the one generic one if that is better.

[Sergio0694]

Updated diff, sizoscope doesn't report everything but the .dll-s are actually 310 KB smaller!! 🎉