[clang] [APINotes] Diagnose invalid Where.Parameters selectors (PR #209408)
via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 22 02:14:21 PDT 2026
================
@@ -893,6 +911,80 @@ APINotesReader::Implementation::getIdentifier(llvm::StringRef Str) {
return *Known;
}
+std::optional<llvm::StringRef>
+APINotesReader::Implementation::getIdentifierString(IdentifierID ID) {
+ if (!IdentifierTable)
+ return std::nullopt;
+
+ if (ID == IdentifierID(0))
+ return llvm::StringRef();
+
+ if (!IdentifierStringsInitialized) {
+ IdentifierStringsInitialized = true;
+ // keys() and data() iterate over the same serialized entries in lockstep,
+ // so build the reverse cache without doing a lookup for each key.
+ auto Identifiers = IdentifierTable->keys();
+ auto IDs = IdentifierTable->data();
+ auto Identifier = Identifiers.begin();
+ auto KnownID = IDs.begin();
+ auto IdentifierEnd = Identifiers.end();
+ auto KnownIDEnd = IDs.end();
+ for (; Identifier != IdentifierEnd && KnownID != KnownIDEnd;
+ ++Identifier, ++KnownID) {
+ unsigned Index = static_cast<unsigned>(*KnownID);
+ if (IdentifierStrings.size() <= Index)
----------------
StoeckOverflow wrote:
The current `resize(ID + 1)` form is needed because the vector index is the identifier ID. Even if the table visits IDs out of order, we still store each
string at `IdentifierStrings[ID]`. `push_back` would change the meaning of the vector index to iteration order. That would only be correct if the table visited identifiers densely in increasing ID order, which `OnDiskIterableChainedHashTable` does not guarantee.
I agree that the vector shape is not ideal here. A `DenseMap<uint32_t,
StringRef>` would keep the same ID-based lookup semantics without depending on ID order or growing the vector to fit the largest identifier ID seen, so I think that is the cleaner choice.
https://github.com/llvm/llvm-project/pull/209408
More information about the cfe-commits
mailing list