Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting NullabilityInfoContextSupport=false prevents ILLink.Substitutions.xml from being removed from System.Runtime.InteropServices.dll #2661

Open
Tracked by #12657 ...
rolfbjarne opened this issue Feb 28, 2022 · 3 comments

Comments

@rolfbjarne
Copy link
Member

Test case: consoleapp-d3255da.zip

Repro:

$ make resources-there
dotnet publish /bl /v:quiet /nologo /bl:resources-there.binlog /p:NullabilityInfoContextSupport=false
/usr/local/share/dotnet/sdk/6.0.201/MSBuild.dll /nologo -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/local/share/dotnet/sdk/6.0.201/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/local/share/dotnet/sdk/6.0.201/dotnet.dll -maxcpucount -property:NullabilityInfoContextSupport=false -restore -target:Publish -verbosity:m /v:quiet /bl /bl:resources-there.binlog ./myproject.csproj

Workload updates are available. Run `dotnet workload list` for more information.
monodis --manifest ./bin/Debug/net6.0/osx-x64/publish/System.Runtime.InteropServices.dll
Manifestresource Table (1..2)
1: public 'FxResources.System.Runtime.InteropServices.SR.resources' at offset 0 in current module
2: public 'ILLink.Substitutions.xml' at offset 2505 in current module

Note there are two resources in the ./bin/Debug/net6.0/osx-x64/publish/System.Runtime.InteropServices.dll assembly.

Now try enabling NullabilityInfoContextSupport:

$ make resources-gone
dotnet publish /bl /v:quiet /nologo  /bl:resources-gone.binlog /p:NullabilityInfoContextSupport=true
/usr/local/share/dotnet/sdk/6.0.201/MSBuild.dll /nologo -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/local/share/dotnet/sdk/6.0.201/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/local/share/dotnet/sdk/6.0.201/dotnet.dll -maxcpucount -property:NullabilityInfoContextSupport=true -restore -target:Publish -verbosity:m /v:quiet /bl /bl:resources-gone.binlog ./myproject.csproj

Workload updates are available. Run `dotnet workload list` for more information.
monodis --manifest ./bin/Debug/net6.0/osx-x64/publish/System.Runtime.InteropServices.dll
Manifestresource Table (1..1)
1: public 'FxResources.System.Runtime.InteropServices.SR.resources' at offset 0 in current module

and ILLink.Substitutions.xml has been linked away.

bin logs (remove the .txt extension):

resources-gone.binlog.txt
resources-there.binlog.txt

@vitek-karas
Copy link
Member

This is a bit of a weird case. The System.Runtime.InteropServices.dll has substitutions but also type forwarders.
We try to process substitutions lazily, so only when we need them. That means we only process them if the linker actually processes a method or a field from a given assembly (as nothing else is affected by substitutions).

In the "gone" case the app actually uses some real members from the assembly and so we process the substitutions. Part of this processing is removing the resource from the assembly.

In the "there" case the app doesn't use any member from the assembly, it only uses a type forwarder (System.Runtime.InteropServices.NFloat). In this case we keep the assembly and the type forward in question, but remove everything else from the assembly (there's no types other than <Module>). In this case we don't get to process the substitutions at all (no need) and thus we don't remove them from the assembly.

@sbomer I don't remember the exact details about processing substitutions lazily, but it feels like we should remove the resource from MarkAssembly regardless if we actually need the substitutions. Similarly for linker attributes resource.

@marek-safar
Copy link
Contributor

but it feels like we should remove the resource from MarkAssembly regardless if we actually need the substitutions. Similarly for linker attributes resource.

Yep, it looks like a bug to me too.

@spouliot
Copy link
Contributor

spouliot commented Feb 28, 2022

Note that this happens not just for the ILLink.Substitutions.xml resource file.

The resource file FxResources.System.Runtime.InteropServices.SR.resources is also present, after linking. It should be removed from the assembly just like others are (e.g. from System.Private.CoreLib.dll) since the option to remove those resources are enabled by default.

Never mind. Processing ILLink.Substitutions.xml should be enough to remove FxResources.System.Runtime.InteropServices.SR.resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants