-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
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
New issue has not been triaged by the area owner
label
Jul 1, 2024
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
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
There is an active PR which will close this issue when it is merged
label
Sep 6, 2024
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
in-pr
There is an active PR which will close this issue when it is merged
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: