ILLink should build type info after custom steps run for a type #104266
Assignees
Labels
area-Tools-ILLink
.NET linker development as well as trimming analyzers
in-pr
There is an active PR which will close this issue when it is merged
Milestone
Comments
dotnet-policy-service
bot
added
the
untriaged
sbomer
added
area-Tools-ILLink
|
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas |
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).
dotnet-policy-service
bot
added
the
in-pr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context: #103987 (comment)
Custom steps rely on the ability to add methods to a type. This only works if the
TypeMapInfocache 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.
The text was updated successfully, but these errors were encountered: