SourceLink returning incorrect PDB info

[333fred]

Version Used: 4.13.0-2.24561.3 (24e1dd6)

Steps to Reproduce:

1. Paste this code into a .NET 9 template:

IEnumerable<string>? s = null;

2. Make sure dotnet.navigation.navigateToSourceLinkAndEmbeddedSources is enabled in vscode. Or, if using vs, make sure sourcelink is enabled there.
3. Go-to-def on IEnumerable

Expected Behavior:

SourceLink opens https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/IEnumerable.cs

Actual Behavior:

SourceLink opens https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/TypeUnloadedException.cs.

[dibarbet]

This issue appears to be specific to type definitions that are not an implementation, for example an interface like IEnumerable<T> or delegate Action<T>

Considering the attached DLL and PDB pair (see bottom of message)

1. the typedef table (metadata) row 2624 has token 33557056
2. the customdebuginformation (debug metadata) at row 948 has parent 33557056 (matching 1) - this entry has the comprressed integer that points to the TypeInitializationException document in the documents table (wrong)

Previously, non implementation types were not ever added to the Documents table at all. And this appears to be the case in this instance as well, IEnumerable.cs is not present.

However - support for non implementation types in the documents table was added in #56278 (3 yrs ago),
so they should be in the documents table.

I think the next step is to see if the compiler is writing the correct output into the pdb (with both the item added to the documents table and the customdebuginformation pointing to it).

dllandpdb.zip

[davidwengier]

I verified the compiler changes in #56278 seem to still be working fine:

A TypeDef for an inteface (02000003)

Gets CustomDebugInformation record added for it

and a Document record, which is pointed to by the value in the CustomDebugInformation:

The System.Private.CoreLib.pdb has a CustomDebugInformation record for IEnumerable<T>, but not a Document record, which is odd given both were added in the same PR. I wonder if some part of the runtime build process strips out parts of a PDB, or combines parts of different PDBs, or something weird.

@stephentoub @tannergooding @jkoritzinsky do you know if the runtime build does anything interesting here?