[ObjC] Store Objective-C metadata in the database instead of regenerating it on load - #8411
Open
bdash wants to merge 1 commit into
Open
[ObjC] Store Objective-C metadata in the database instead of regenerating it on load#8411bdash wants to merge 1 commit into
bdash wants to merge 1 commit into
Conversation
…ting it on load Processed Obj-C metadata was stored ephemerally on the view and not serialized to the .bndb. On reopen the Obj-C processor had to be re-run on every loaded image to regenerate the metadata, which caused many functions to be reanalyzed due to types and symbols being reapplied. Commit 1bb0012 tried to suppress that from inside `DefineObjCSymbol` but ended up skipping method type application on fresh shared-cache loads. As a result, methods whose names were already in the symbol table (some methods in macOS shared caches) did not have argument types applied. We now save the Objective-C metadata to the .bndb and only process Objective-C data in the binary if the metadata is absent or out of date. Additionally, each `ProcessObjCData` call now merges its output into any existing metadata so multiple shared cache images accumulate metadata into a single unified object instead of clobbering each other. An "Objective-C Literals" metadata key is added with its own version, so future changes to Obj-C literal processing can force reprocessing on existing databases without touching the main Obj-C metadata version. The changes made to `ObjCProcessor` in 1bb0012 are reverted as they were incorrect and are no longer needed with this new approach. Fixes #8087.
emesare
reviewed
Aug 13, 2026
| { | ||
| QualifiedName classTypeName = cls.name; | ||
| std::string classTypeId = Type::GenerateAutoTypeId("objc", classTypeName); | ||
| if (m_data->GetTypeById(classTypeId)) |
Member
There was a problem hiding this comment.
What was the purpose of moving this and removing the check, I assume this means that there is never any duplicate class type names?
Contributor
Author
There was a problem hiding this comment.
This specific code comes from 1bb0012, and was part of trying to make processing Obj-C runtime metadata twice a no-op.
This new approach uses metadata stored on the view to know that it should entirely skip doing Obj-C processing when loading from a database, rather than trying (and failing) to make it into a no-op to process Obj-C runtime metadata twice.
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
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.
Processed Obj-C metadata was stored ephemerally on the view and not serialized to the .bndb. On reopen the Obj-C processor had to be re-run on every loaded image to regenerate the metadata, which caused many functions to be reanalyzed due to types and symbols being reapplied. Commit 1bb0012 tried to suppress that from inside
DefineObjCSymbolbut ended up skipping method type application on fresh shared-cache loads. As a result, methods whose names were already in the symbol table (some methods in macOS shared caches) did not have argument types applied.We now save the Objective-C metadata to the .bndb and only process Objective-C data in the binary if the metadata is absent or out of date. Additionally, each
ProcessObjCDatacall now merges its output into any existing metadata so multiple shared cache images accumulate metadata into a single unified object instead of clobbering each other.An "Objective-C Literals" metadata key is added with its own version, so future changes to Obj-C literal processing can force reprocessing on existing databases without touching the main Obj-C metadata version.
The changes made to
ObjCProcessorin 1bb0012 are reverted as they were incorrect and are no longer needed with this new approach.Fixes #8087.