A C++ name is looked up from where it is written, and a class that a
source file defines belongs to that file's translation unit, so only that
file sees it (#2538). A header that declares `struct Rep;` and
`std::unique_ptr<Rep> rep_;` writes the name for a `Table::Rep` that its
source file defines, and code in that file reads the member through it.
The lookup ran from the header, saw no source file's classes and found
nothing. The call was then guessed by the method's name, often onto the
calling class's own method:
- leveldb's `rep_->index_block->NewIterator(…)` reached
`Table::NewIterator`;
- rocksdb's `rep->write_batch.GetDataSize()` reached
`WriteBatchWithIndex::GetDataSize`;
- rocksdb's `level_iters_[i]->status()` reached `ForwardIterator::status`.
cppClassWritten's lookup now also sees the classes of the file the
reference is in, the translation unit that includes the header
(visibleFrom(file, unit)). classNode filters by that same visibility
instead of recomputing the header's.
A member-chain diagnostic on main 81fd0078 found 99 rocksdb and 7 leveldb
chain calls through a `Rep` whose class couldn't be placed.
Kit A/B against main 5994edb3:
| repo | removed | added | retargeted | same target, now typed |
|---|---|---|---|---|
| rocksdb | 34 | 40 | 43 | 56 |
| fmt | 0 | 27 | 0 | 1 |
| protobuf | 25 | 1 | 2 | 2 |
| leveldb | 0 | 1 | 3 | 3 |
| redis | identical | | | |
- Retargeted: from the calling class's own method or a namesake to the
member's class:
- rocksdb: WriteBatch, ForwardLevelIterator, IndexBuilder and
PartitionedIndexBuilder, RangeDelBlockBuilder, Env, MemFile;
- leveldb: Block::NewIterator;
- protobuf: DescriptorPool::Tables::FindSymbol.
- Removed: calls on library members reached this way, which had linked to
namesakes:
- `std::stack::pop` (BinaryHeap::pop);
- `std::vector::size` (Block::size);
- `std::thread::join` (WindowsThread::join);
- absl::flat_hash_set's `clear` (Map::clear);
- `std::optional`'s `has_value` and `reset` (Option,
ScopedPythonPtr).
- Added:
- WriteBatch's Put, Delete, Merge and the rest, through
WriteBatchWithIndex's `rep->write_batch`;
- gtest's UnitTestImpl through `impl()`, in fmt's and rocksdb's vendored
gtest;
- leveldb's FilterPolicy::Name.
- About 35 changed sites read by hand were all right.
Mutations: dropping the unit from visibleFrom, or from the lookup's call,
fails the new tests. classNode's own filter only chooses among several
declarations of one class, and nothing on the kit or in the tests has two,
so dropping it survives.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A TEST_F / TEST_P body is a member function of a class derived from its
fixture, so its unqualified names find the fixture's nested types (its bases'
included) before the enclosing namespaces'. And since the index names a
function's local class after the function, every TEST_F body's local `FakeWF`
or `MyManager` shared one qualified name: a class local to a function is now
visible only from inside that function, and a namesake class's methods are
its own body's.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Receiver typing resolved a C++ call on a variable, parameter or member by
the declared type's last name: `Iterator* iter; iter->Valid()` became
resolveMethodOnType('Iterator', 'Valid'), which takes any class named
`Iterator` that declares `Valid`. facebook/rocksdb has 22 such classes,
and the `Iterator` the code means inherits `Valid`, `Next` and `key` from
`IteratorBase`, so nested namesakes like `MemTableRep::Iterator` took the
calls (google/leveldb's went to `SkipList::Iterator`).
A declaration the calling function or its class writes, called with the
operator it takes (`->` on a pointer, `.` on a value or reference), now
goes through the same C++ lookup #2440 uses for smart pointers'
held types (cppClassWritten from the caller's scopes, then the file's
`using`s, aliases followed) and cppMethodOf (the class's own method, else
one through its own base edges):
- An alias #2399 followed from the caller (function-local typedefs
included) is the class it names, by qualified name. An `auto` loop's
element type (#2492) is looked up where its range's type is written.
- A class found only as the one class of that name the file can see, a
template parameter's type, a library type, or a type nothing visible
declares: the call goes on as before.
- A class with no such method gets no edge, unless it is a class template
or a base on the way is one the index doesn't link (a `decltype(…)`
base, an alias each `#if` arm declares differently), which may declare
it: then as before.
- Declarations read from elsewhere, or past one the scan couldn't read,
are unchanged.
cppClassWritten now tries the file's `using`s before the global scope:
protobuf's upb generator writes `using google::protobuf::Descriptor;`
inside its namespace, and the PHP extension declares a global C struct
`Descriptor` in a header.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A C++ call made with `->` on a receiver the calling function or its class
declares as a `std::unique_ptr<T>`, `std::shared_ptr<T>` or
`std::optional<T>` now resolves on `T`: on the class C++ name lookup finds for
it where the call is written, or on a class that class derives from. Before,
receiver inference read the type as `unique_ptr`, found no method, and the
call fell through to the guess by method name: rocksdb's
`std::unique_ptr<Iterator> iter; iter->Valid()` reached
`ArenaWrappedDBIter::Valid`.
The held type goes through #2407's lookup (`cppClassWritten`, extracted from
`matchCppSupertype`), not `resolveMethodOnType` on its last name: rocksdb has
22 classes named `Iterator`, and the one the calls mean inherits its methods
from `IteratorBase`, so a last-name lookup reaches `MemTableRep::Iterator`.
The method is taken from that class or its bases through the class's own
extends edges (`getSupertypeNodes`). A template parameter, a library type or
an alias of one gets no edge; a type the project doesn't declare, or an alias
the lookup can't follow, leaves the call as it was.
The namespace-macro helpers move from name-matcher.ts to cpp-namespaces.ts
unchanged, so name-matcher can import cpp-supertypes without a cycle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
normalizeCppTypeName cut each `<…>` at its first `>`, so a declared type
with template arguments nested in its template arguments kept debris:
`autovector<std::pair<int, FileMetaData*>>` read as `autovector >` and
`Striped<CacheAlignedWrapper<port::Mutex>>` as `Striped >`. No class has
such a name, so the call was never resolved on the receiver's class. A
capitalized debris name made isUndeclaredTypeName take the type for an
outside one and silence the call (rocksdb's `mutex_.Get(key)`), and a
lowercase one fell to a guess by the receiver's words (rocksdb's
`files_marked_for_compaction_.clear()` reached `CompactionInputFiles::clear`).
Template arguments are now stripped with their nesting by
cpp-type-aliases' depth-tracking helper, exported as
stripCppTemplateArguments; cpp-supertypes' identical private copy now
imports it. A `>` that closes no `<` is the end of a declaration begun on
an earlier line (`std::unique_ptr<BlobContents>>>& blob_reqs` under
`autovector<std::pair<…,`): a depth strip alone would read the argument's
type there, so such text names no type. The scan back to the receiver's
declaration then marks it shadowed (#2413), as it does for a declaration
whose type it can't read, so a member or earlier variable of the same
name found further up doesn't decide the call.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A C++ base class (`class DynamicMessage final : public Message`) was
resolved by its name alone, so a base named like a class of another
namespace, or of another language, bound to whichever namesake ranked
first. In protocolbuffers/protobuf, `DynamicMessage`, `MapEntry`,
`ZeroFieldsBase` and two arena_unittest classes derived from
`json_internal::ResolverPool::Message`; before #2397 they derived from the
PHP extension's C struct `Message`. The Go framework resolver claimed
those: protobuf ships Go examples, so the resolver is detected, its
`resolve()` runs for every language's refs (`languages` only gates
extraction), its PascalCase-struct rule found the C struct, and the
framework language gate lets C++ reach C. google/leveldb's and rocksdb's
iterators derived from an unrelated nested `Iterator` (`SkipList::Iterator`,
`WriteThread::WriteGroup::Iterator`), and leveldb's test comparators from a
`Comparator` struct that skiplist_test.cc declares for itself.
C and C++ inheritance refs now resolve in their own matcher
(cpp-supertypes.ts), ahead of every other strategy and with no
fallthrough, so no framework resolver, import strategy or name matcher sees
them, and only C and C++ declarations are candidates. The base is looked
up the way C++ looks it up:
- from the scope the deriving class is declared in, outwards, using the
lookup cpp-type-aliases.ts (#2399) already has: a class scope with its
bases, a qualified name a segment at a time, an alias followed to the
class it names; `::Base` from the global scope only;
- then through what the file writes before the class: namespace aliases
(`namespace _pbi = ::google::protobuf::internal;`), using-declarations
and using-directives, and fmt's macro-opened namespaces;
- a class a .cc/.c file defines belongs to that translation unit;
- a template parameter, or a member of one, names no class: no edge.
When none of that finds the class, the only visible C/C++ class with that
qualified tail is taken, since the index loses some classes' namespaces
(`class PROTOBUF_EXPORT FieldDescriptor`, classes after a partial
specialization); several are a guess, so no edge.
The base is read as written, template arguments included, so an alias
template (`bool_constant<…>`) is found. An alias that leads to no project
class (one of `std::integral_constant`, one each `#if` arm declares
differently) is linked itself, as before.
Validated with site-keyed edge diffs on leveldb, fmt, protobuf and
rocksdb, and redis, SDWebImage and gson as controls (dumps
byte-identical): first against main 02d22aeb, then again on main
dd706469 after #2405, #2408 and #2400 landed, with identical site
diffs (#2402, merged after, changes only Go's implements synthesis).
Every removed edge was wrong: 9 protobuf
`suite_.ReportFailure` guesses that reached `ForkPipeRunner`, cpp-override
edges from the wrong bases, and two rocksdb bases that are template
parameters.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
