LibraryImport analyzer crashes when encountering certain attributes

[tannergooding]

Repro

1. git clone https://github.com/terrafx/terrafx.interop.windows
2. Open the solution in VS 2022 (17.4.0 Preview 2.0)
3. Build (and wait a minute or so)

Expected Behavior

The analyzer works and reports any bugs.

Actual Behavior

Severity	Code	Description	Project	File	Line	Suppression State	Detail Description
Error	AD0001	Analyzer 'Microsoft.Interop.Analyzers.CustomMarshallerAttributeAnalyzer' threw an exception of type 'System.InvalidOperationException' with message 'Sequence contains no elements'.	TerraFX.Interop.Windows (net6.0)	D:\Users\tagoo\source\repos\terrafx.interop.windows\sources\Interop\Windows\CSC	1	Active	Analyzer Failure
Error	AD0001	Analyzer 'Microsoft.Interop.Analyzers.NativeMarshallingAttributeAnalyzer' threw an exception of type 'System.InvalidOperationException' with message 'Sequence contains no elements'.	TerraFX.Interop.Windows (net6.0)	D:\Users\tagoo\source\repos\terrafx.interop.windows\sources\Interop\Windows\CSC	1	Active	Analyzer Failure

[tannergooding]

Sorry for the "non-simple" repro. I've seen it repro in smaller repos, like ClangSharp, as well but those aren't in a state that make it as "simple" as just opening the solution, starting a build, and waiting.

TerraFX.Interop.Windows is also a "good" stress-test case for the analyzer as it defines some 7306x DllImport methods, all of which are blittable. -- If the error case above is disabled, then there are some 11k informational messages for SYSLIB1054 reported for the repo. It can notably take several minutes for all of these to be reported.

It's worth noting given the above that every binding in TerraFX is blittable. Having the analyzer report diagnostics for blittable P/Invokes is a bit undesirable to me, personally. While on one hand I can understand the reasoning for simply migrating "everything" over to LibraryImport, it does represent a case that leads to additional metadata bloat, more work on the JIT to remove/inline a method that just calls the actual P/Invoke, and more compilation time to ensure that everything is trimmed, converted, etc.

[tannergooding]

CC. @jkoritzinsky, @AaronRobinsonMSFT

[tannergooding]

Moved to dotnet/roslyn-analyzers#6167

[jkoritzinsky]

The PlatformCompatibilityAnalyzer is in dotnet/roslyn-analyzers and is owned by the libraries team (I think Jeff Handley's team). Can you open a separate issue for that one?

[jkoritzinsky]

Also, for blittable bindings, we don't generate a method that calls a P/Invoke. We add the DllImport attribute to the LibraryImport method, making it the P/Invoke itself. So the extra metadata cost is just the LibraryImport attribute, which will be removed when trimming agressively (the mode that removes some attributes). As a result, there's no extra JIT work to make blittable P/Invokes as efficient in comparison to using DllImport.

[jkoritzinsky]

I've root-caused this bug. The mechanism we use to go from an AttributeSyntax to an AttributeData doesn't account for an attribute on a local function. In that case, the containing symbol is the outer method, but we need to inspect the local function to get the AttributeData.