Signature parsing and GetFieldDescData cDAC API

[rcj1]

• Adding SignatureDecoder contract (currently an abstraction over System.Reflection.Metadata SignatureDecoder with an implementation of SignatureTypeProvider.
• Adding GetFieldDescData cDAC API and required helpers

[Copilot]

Pull Request Overview

This PR adds signature decoding capabilities to the cDAC (Compact Data Access Component) by implementing a new SignatureDecoder contract and the GetFieldDescData API. The implementation leverages System.Reflection.Metadata for signature decoding with a custom SignatureTypeProvider.

Key Changes

• Adds SignatureDecoder contract with field signature decoding capability
• Implements GetFieldDescData cDAC API for retrieving field descriptor information
• Adds required data structures and helper methods for field descriptor access

Reviewed Changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
SOSDacImpl.cs	Implements GetFieldDescData with signature decoding and field information extraction
ISOSDacInterface.cs	Defines DacpFieldDescData structure and updates interface signature
SignatureDecoder_1.cs	Core signature decoder implementation using System.Reflection.Metadata
SignatureTypeProvider.cs	Custom type provider for signature decoding with runtime type system integration
RuntimeTypeSystem_1.cs	Adds field descriptor APIs and GetMethodTable implementation
Various data/contract files	Adds new data structures, constants, and contract registrations

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[rcj1]

#119625 (comment)

[rcj1]

We are using the CorElementType defined in the RuntimeTypeSystem abstraction as our CorElementType in the ISOS interface and in the cDAC APIs. This contains two internal types. We should expose these in a cleaner way; that is out of scope for this PR and I have created an issue for it
#119971

[noahfalk]

LGTM

I agree that an O(n) search for generic types may not be fast enough to ship the scenario but I don't think it needs to block this specific PR. I suspect we may want to upgrade it to a hashed lookup in the future.

[rcj1]

LGTM

I agree that an O(n) search for generic types may not be fast enough to ship the scenario but I don't think it needs to block this specific PR. I suspect we may want to upgrade it to a hashed lookup in the future.

I can open up a tracking issue for this; I gathered that this is a more lengthy discussion of how to port this specific hash (if at all) from the runtime to the cDAC while minimizing the complexity of runtime internal involved, and there out of scope for this specific PR.

[jkotas]

I can open up a tracking issue for this;

Yes, we should have a tracking issue for this.

[rcj1]

I can open up a tracking issue for this;

Yes, we should have a tracking issue for this.

Done
#120008