fix(cpp): a smart pointer's held class lacking a method gets no edge only when its bases are known

[colbymchenry]

Summary

Follow-up to #2493. A -> call on a std::unique_ptr / std::shared_ptr / std::optional whose held class has no method of that name (own or inherited) now gets no edge only when the class's bases are all known — the same rule #2493 applies to raw pointers, values and references. When a base on the way is one the index doesn't link, the call goes on as before.

Why

matchCppHeldTypeCall (#2440) returned null for a held class lacking the method unless it was a class template. #2493 measured the gap in that rule on the raw-pointer path: a base the index can't link may declare the method.

• protobuf: class FlatAllocator : public decltype(ApplyTypeList<FlatAllocatorImpl>(…)) has no extends edge to FlatAllocatorImpl, so 95 right alloc.PlanArray(…) → FlatAllocatorImpl::PlanArray edges would have been dropped.
• rocksdb: WritePreparedTxnDB : public WritePreparedTxnDBBase, an alias each #if USE_COROUTINES arm declares differently.

What changed

• New cppLacksMethod(cls): not a class template, and cppBasesKnown(cls) (every base each declaration writes, at every level, is linked by an extends edge to a class or is a library type such as std::runtime_error).
• matchCppHeldTypeCall and matchCppDeclaredTypeCall both use it, so the two paths can't drift apart.
• Doc comments updated (the declared-type one hadn't mentioned the base check).
• CHANGELOG: fix(cpp): a -> call on a smart pointer or optional reaches the type it holds #2440's [Unreleased] bullet now states the final rule. Neither fix(cpp): a -> call on a smart pointer or optional reaches the type it holds #2440 nor fix(cpp): a call on a declared pointer, value or reference reaches the class its type names, not a namesake #2493 has shipped (latest release is 1.6.2), so a separate bullet would describe a change no user saw.

Validation

Main 80e4b459 vs this branch, full index of each repo (kernel included), dumps compared by natural keys:

repo	result
google/leveldb	byte-identical
fmtlib/fmt	byte-identical
redis (C control)	byte-identical
facebook/rocksdb	byte-identical
protocolbuffers/protobuf	byte-identical

A probe on the held path explains why: rocksdb has 13,832 held-type calls whose class the lookup finds; 13,829 find the method, 2 are class templates, and the 1 remaining class has fully known bases. protobuf: 248, all find the method. So on these repos the change guards a shape they don't hit through smart pointers; it matters where a held class derives from a decltype(…) or #if-varying alias, as the test pins. No CPU run: the new check runs only when the method was not found (3 rocksdb calls).

Tests

• __tests__/cpp-smart-pointer-receiver.test.ts: a held std::unique_ptr<internal::FlatAllocator>& whose class derives from a decltype(…) keeps main's FlatAllocatorImpl::PlanArray edge. It fails with main's held-path line restored, and passes here.
• The C++ resolution suites pass: 311 tests, 0 failures.

🤖 Generated with Claude Code