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

ILLink should build type info after custom steps run for a type #104266

Open
sbomer opened this issue Jul 1, 2024 · 1 comment
Open

ILLink should build type info after custom steps run for a type #104266

sbomer opened this issue Jul 1, 2024 · 1 comment
Labels
area-Tools-ILLink .NET linker development as well as trimming analyzers
Milestone

Comments

@sbomer
Copy link
Member

sbomer commented Jul 1, 2024

Context: #103987 (comment)

Custom steps rely on the ability to add methods to a type. This only works if the TypeMapInfo cache for that type is built after the custom step gets a chance to process the type, otherwise we miss interface methods that are implemented by the custom step.

As far as I can tell this was never guaranteed, and is heavily order-dependent. To make this guarantee for custom steps we might need to build the type info cache per type, instead of per assembly, and ensure it never gets built for a type before we call into the custom step for a type.

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jul 1, 2024
@sbomer sbomer added area-Tools-ILLink .NET linker development as well as trimming analyzers and removed area-System.Reflection untriaged New issue has not been triaged by the area owner labels Jul 1, 2024
Copy link
Contributor

Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas
See info in area-owners.md if you want to be subscribed.

@sbomer sbomer added this to the 9.0.0 milestone Jul 1, 2024
sbomer added a commit that referenced this issue Jul 2, 2024
See
#103987 (comment)
for context.

Custom steps rely on getting a chance to see a type before we
build the type info (and in particular the interface method
mapping), but we make no such
guarantee. #104266 tracks
this problem.

Our use of the dependency analysis framework exacerbated this
because `MarkType` was split into two pieces, with the part that
calls into the custom step being delayed through a dependency
analysis framework node, making it more likely to be run too late
to influence the type info.

This reverts ILLink's usage of the dependency analysis framework
to bring us back to a state where the ordering still isn't
guaranteed, but works for the testcase that got regressed. We
should bring this back as soon as possible with a proper fix that
actually guarantees the ordering required by custom steps. This
doesn't look completely straightforward, but should be possible
to do with the dependency analysis framework.

Fixes #103987 (but we
need a better long-term fix for
#104266).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Tools-ILLink .NET linker development as well as trimming analyzers
Projects
Status: No status
Development

No branches or pull requests

1 participant