91830f1e0e68232e991902b0fa7617651d2eee15
1
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
91830f1e0e |
feat(managed): name the declaring type of call and field targets (#2163)
* feat(managed): name the declaring type of call and field targets Call edges named external targets by member name alone (Join, ToJson, WriteAllText), and method-spec edges had no name at all, so an analyst could not tell which library a method calls or find every use of a type without a decompiler. Field accesses through MemberRefs had no name either. Name each TypeDef, TypeRef, and generic-instantiation TypeSpec once, in the namespace-qualified form TypeDef full_name uses, and add member_refs parent_name, call_edges target_declaring_type, and field_accesses field_declaring_type. A method-spec target reports the generic method it instantiates. Fields, member references, methods, and method specs now resolve through one token-keyed MemberCore lookup instead of three maps. Evidence recorded before these fields reads them as null. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): validate spec blobs and member kinds before naming targets Address review findings on declaring-type naming: - A generic instantiation must name a TypeDef or TypeRef, so a TypeSpec base is reported as malformed instead of followed. Naming no longer recurses. - TypeSpec and MethodSpec instantiation blobs are decoded with the member-signature grammar. Malformed blobs and out-of-range TypeDef rows are reported against their owning row and make coverage partial. - A MethodSpec reads both columns. An invalid Method coded index is reported; a readable Method keeps its name beside a malformed instantiation. - MemberCore carries its signature kind, so a field operand is named only by a field or field-signature MemberRef. This replaces the token-table guard. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): validate MethodSpec arity and report unsupported spec blobs - A MethodSpec now checks that its method signature is generic and that the instantiation supplies as many type arguments as it declares. A non-generic target, a field reference, or a count mismatch is reported as invalid-row; the readable method keeps its name. - Unsupported TypeSpec and MethodSpec forms raise an owner-scoped unsupported-signature issue instead of reading as an intentional unknown. - MethodSpec reading moves to ManagedMethodSpecs.ts, and its tests get their own describe block. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): reject non-method signature headers and invalid TypeRef scopes The method signature header reader now owns the calling-convention rule that only FNPTR applied: FIELD, LOCAL_SIG, PROPERTY, and GENERICINST headers, the reserved bit, and EXPLICITTHIS without HASTHIS are malformed. A MethodSpec whose method has a PROPERTY header is no longer accepted as a generic method, and member signatures with such headers no longer decode as methods. The type-name lookup validates a TypeRef's ResolutionScope coded index and reports an out-of-range scope as invalid-row, keeping the readable name. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): hold member rows to MethodDefSig and FieldSig headers Method signature headers are now checked in context. MethodDef and MemberRef rows accept only the MethodDefSig/MethodRefSig headers: DEFAULT, VARARG, or GENERIC with DEFAULT. FNPTR keeps the unmanaged conventions compilers emit for function pointers. A field signature must be exactly FIELD, so a flagged FIELD header is malformed and never names a field. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): accept MethodSpec arity only from a fully decoded signature The arity check read only the target's signature header, so a truncated generic method signature passed. Under type selection a MethodDef target outside the selection is never decoded elsewhere, so coverage stayed complete. The arity now comes from a transient full decode, and only a decoded method signature supplies it. signature() keeps its raw length and digest around the shared decodeSignature. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * perf(managed): decode each MethodSpec target signature once edgeTargets caches the generic arity, including a failed decode, by target method token, so many instantiations of one generic method share a single signature decode. Unity.InputSystem has 472 distinct MethodSpecs over about 133 target methods. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): validate spec type operands and transitive reference scopes * fix(managed): retain readable names when a scope row is unreadable * test(managed): pin owner-scoped spec operand and scope-chain checks e59217c83 validates spec type operands inside specSignature, so a malformed generic TypeSpec base is now invalid-row under its owning TypeSpec row; the three stale expectations follow that. New cases cover a TypeSpec argument and a MethodSpec argument that name a missing TypeRef, and a TypeRef whose ResolutionScope names itself. The scope cases move to their own describe block. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): keep field targets from naming MethodSpecs A MethodSpec over a field-signature MemberRef inherited kind "field", so an ldsfld on that MethodSpec published a field name and declaring type for malformed IL. A MethodSpec now borrows its target's name only when the target is not a field; the arity check still reports it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(managed): reuse owner-decoded signatures for MethodSpec arity MemberRef signatures, and MethodDef signatures in the type selection, are already fully decoded, but the MethodSpec arity check decoded them again and admitted a second transient allocation, which could exhaust the budget. MemberCore now carries the owner's genericArity, and only a target nothing decoded, such as an unselected MethodDef, falls back to the raw signature. signatureGenericArity is the one rule for both paths. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: morluto <76467478+morluto@users.noreply.github.com> |