[3.0] Rework the structure of PrettifyNames#2564
Draft
Exanite wants to merge 132 commits intodotnet:develop/3.0from
Draft
[3.0] Rework the structure of PrettifyNames#2564Exanite wants to merge 132 commits intodotnet:develop/3.0from
Exanite wants to merge 132 commits intodotnet:develop/3.0from
Conversation
…ld used by other bindings The default acronym threshold was changed during #29, which was merged as part of dotnet#2503.
Considering we decided to follow Microsoft's Framework Design Guidelines (acronym threshold of 2) for the bindings and rest of the API, might as well be consistent here.
… separation hack (no longer necessary)
…mbers are normalized
This lets us handle prefixing and prettification separately, which notably is important if we add prefixes after prettification. We want to prefix the final name, not the intermediate name in this case.
…igured (cherry picked from commit bc94260)
…ous that it is not the last trimmer
This no longer makes sense to keep and enabling features by baseline version seems fiddly. If we need to toggle features for newer versions, we can explicitly add a boolean config option.
…essor and ReapplyAffixesNameProcessor
Kinda a cop out decision, but it keeps thing simple (and thus maintainable) and implementing it fully seems overkill for what we need.
… for function pointer types are named
This is because we no longer output the separating underscore in ExtractNestedTyping
… of INameTrimmer registrations
…ed-struct-name-affixes
…nvention Note that the goal is to eventually remove the name overrides for the `EFXEAXREVERBPROPERTIESflLateReverbPan` and `-Delegate` cases entirely. This is because these are theoretically possible to handle automatically and the reason it doesn't work is due to an edge case interaction with the name override system. See the "Tasks" section here for more info: dotnet#2555
…thod names being mixed together now
…ng the rest of the pipeline as INameProcessors
…n lead to inefficient data access
…names from the final to working set
…dditionalDiscriminatorAffixes
This wasn't an actual observed issue, but is a possible edge case I noticed when I was reading the code. The underlying data collection is a hashset or dictionary, both of which have non-deterministic iteration order. This commit adds a tie-breaker to prevent this issue from possibly happening.
…inatorAffixes_ReversedPriority and add more comments on why the tests exist
…ot getting chosen properly
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of the PR
(WIP)
Context
This PR chains off of #2557 and completes the final tasks noted in the PR.
This is a separate PR since this PR has a fundamentally different focus than #2557: this PR focuses on PrettifyNames itself while #2557 focuses on moving the prefix trimming code out of PrettifyNames.
What the PR does
The core goal of this PR is to make PrettifyNames easier to understand.
I also put some effort to optimize things where possible (note I haven't done any profiling yet, so nothing is conclusive).
This PR rewrites the core PrettifyNames logic to be done by "INameProcessors", which are sequential processing steps that each apply transformations to the names in the generated bindings.
INameProcessorreplaces the oldINameTrimmerinterface.Additionally,
INameProcessoris private toPrettifyNamesunlikeINameTrimmerwhich used to be able to be implemented by mods and other services present in the DI container.This change was done because there are other ways to extend and configure the PrettifyNames logic now, meaning that
INameTrimmer/Processoris no longer needed as an external extension point.Additionally, with this rewrite, I've cleaned up the storage of names and the way that symbols are retrieved prior to renaming.
Related issues, Discord discussions, or proposals
The "parent" PR: #2557
Further Comments
(TODO: Copy over the tasks done in this PR from #2557. My intention is that both PRs have records of what was done and in which PR the changes were implemented.)