Update SPCL to use GeneratedDllImport where possible.

[AaronRobinsonMSFT]

/cc @jkoritzinsky @elinor-fung

[jkoritzinsky]

Can you make sure to run the code-fix on the other target OSes of System.Private.CoreLib as well so we can catch the Linux and MacOS P/Invokes too? I think if you set the TargetOS environment variable before opening VS, you'll be able to override the target OS. Or you can change

runtime/Directory.Build.props

Line 21 in 25da88c

<TargetOS Condition="'$(TargetOS)' == ''">$(_hostOS)</TargetOS>

to Linux, OSX, etc. to cycle through the different OSes in VS.

[stephentoub]

where possible

What remains that's not possible? Do we have a plan to get to 100%, whether by improving the source generator or by changing the P/Invoke signatures or both?

[AaronRobinsonMSFT]

What remains that's not possible? Do we have a plan to get to 100%, whether by improving the source generator or by changing the P/Invoke signatures or both?

@stephentoub The biggest change is the blittable signatures with Guid—we do have a plan. There are also a few scenarios involving marshalling via COM interop that will need to be updated using ComWrappers. So we do have a plan longer term and have added a TODO for each signature with what is needed.

[elinor-fung]

This also doesn't include converting QCalls. Now that @jkoritzinsky has updated how the runtime handles QCalls, we should be able to do another pass over SPCL to convert those as well.

There are also a couple of other things like CriticalHandle, HandleRef, and StringBuilder that the generator doesn't support.

[stephentoub]

Thanks.

There are also a couple of other things like CriticalHandle, HandleRef, and StringBuilder that the generator doesn't support.

But we should be able to update any use of those to not need them, right (or decide to update GeneratedDllImport to support them)? I'm just trying to nudge us to a place where a) we've proven that GeneratedDllImport reasonably can be used exclusively instead of DllImport (using our vast numbers of DllImports in dotnet/runtime as a proxy for real-world usage) and b) we ship .NET 7 without having to generate any stubs at run-time.

[AndyAyersMS]

arm64 regressions (since fixed):

• [Perf] Changes at 11/17/2021 1:35:01 AM perf-autofiling-issues#2405
• [Perf] Changes at 11/17/2021 1:35:01 AM perf-autofiling-issues#2403
  

[EgorBo]

Improvements on windows-arm64: dotnet/perf-autofiling-issues#2555