Skip to content

AssemblySymbol.CorLibrary invariant could be broken #61262

@jcouv

Description

@jcouv

Problem 1:
The compiler expects that AssemblySymbol.CorLibrary is never null, but it is left unset in some EmitDifference scenarios.
In unittest Microsoft.CodeAnalysis.CSharp.Emit.UnitTests.dll!Microsoft.CodeAnalysis.CSharp.EditAndContinue.UnitTests.AssemblyReferencesTests.CompilationReferences_More, a MissingAssemblySymbol with a null CorLibrary is created when CreatePEAssemblyForAssemblyMetadata calls MapAssemblyIdentityToResolvedSymbol and it's left unset.

A temporary workaround was added to the compiler, which should be removed:

                // CorLibrary should never be null, but that invariant is broken in some cases for MissingAssemblySymbol.
                // Tracked by https://github.com/dotnet/roslyn/issues/61262
                return CorLibrary is not null && ...;

Problem 2:
The compiler expects that the symbol in AssemblySymbol.CorLibrary never has any references, but Aleksey and I couldn't convince ourselves that the code in CreatePEAssemblyForAssemblyMetadata guarantees that.
Looking at CreatePEAssemblyForAssemblyMetadata code for problem 1, we noticed that it creates a PEAssemblySymbol and then sets its core library in InitializeAssemblyReuseData (it does assemblySymbol.SetCorLibrary(this.CorLibraryOpt ?? assemblySymbol);).
But it was not clear that this is necessarily the right core library to set. The case where assemblySymbol gets used risks breaking a compiler invariant if this assembly symbol does have references.

var assemblySymbol = new PEAssemblySymbol(assembly, DocumentationProvider.Default, isLinked: false, importOptions: importOptions);
...
InitializeAssemblyReuseData(assemblySymbol, peReferences, unifiedAssemblies);

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions