[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