You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: