[#165 follow-up] Class-interface-implementation diagnostic — cross-file enumeration + inherited-method resolution + overload discrimination

[msarson]

Status

Core diagnostic shipped on version-0.9.7 (commit 65dae3d). This issue now tracks the two remaining refinements (items 2 & 3 below).

Model correction (2026-06-07). Earlier versions of this issue — and the original #165 implementation — assumed an implementing CLASS,IMPLEMENTS(Interface) re-declares the interface's methods in its own body. That is wrong. Verified against the Clarion docs (INTERFACE (class behavior definition), Implementing INTERFACEs in Derived Classes) and the shipping LibSrc (C:\Clarion\Clarion11.1\LibSrc\win):

• The interface's method prototypes live in the INTERFACE structure.
• The implementing class body holds only its own methods/data — never the interface methods. E.g. CSocketConnection CLASS,...,IMPLEMENTS(IConnection) in abapi.inc lists Construct/Destruct/Init/Kill/..., none of IConnection's methods.
• The interface methods are implemented as three-part Class.Interface.Method PROCEDURE definitions in the class's MODULE('x.clw') — e.g. CSocketConnection.IConnection.CloseSocket PROCEDURE in abapi.clw.

The old class-body check would have false-positived on every interface implementation in the shipping library. The diagnostic was rebuilt around the correct model.

What shipped (v1, 65dae3d)

Warns when a non-derived CLASS,IMPLEMENTS(Interface) does not provide an implementation for one of the interface's methods.

• Required methods: resolved from the INTERFACE via the class file's INCLUDE chain (MemberLocatorService.enumerateInterfaceMembers).
• Provided implementations: three-part Class.Interface.Method MethodImplementation tokens collected from:
  • the class's MODULE('x.clw') (collectImplementedInterfaceMethods), or
  • the current document when the class is declared + implemented inline in a PROGRAM/MEMBER source with no MODULE attribute (collectImplementedInterfaceMethodsFromTokens, gated on getDocumentKind()).
• Conservative — no false positives: skips derived classes, declaration-only .inc files with no MODULE, and any case where the interface or implementation source can't be resolved.
• Tests: disk fixture mirroring the LibSrc layout + same-file fixtures, incl. a false-positive guard (fully-implemented class ⇒ no warning).

Remaining scope (this issue)

2. Inherited-implementation resolution for derived classes

v1 skips CLASS(Parent),IMPLEMENTS(...). Per Implementing INTERFACEs in Derived Classes, a derived class may implement only some interface methods — the compiler stubs the rest to jump to the nearest ancestor implementation. To validate derived classes without false positives, walk the parent-class chain (each ancestor's MODULE .clw) and treat an interface method as satisfied if implemented on the class or any ancestor. Many real LibSrc implementers are derived (GridClass CLASS(BrowseClass), SMTPTransport CLASS(TELNETTransport), the FileManager-derived encoders), so this materially widens coverage.

3. Parameter / overload discrimination

v1 matches by method name only. A refinement could compare the three-part implementation's parameter signature against the interface prototype (interface declares Foo(STRING), class implements only Foo(LONG) ⇒ warn), reusing the overload substrate from #125/#127/#128. Higher false-positive risk (signature normalisation), so lower priority.

Cross-references

• Parent: [Pattern A O5] Implement validateClassInterfaceImplementation — wire MemberLocatorService.findInterfaceInIncludeChain #165 (original same-file v1 — superseded by the corrected model)
• Substrate: MemberLocatorService.enumerateInterfaceMembers / collectImplementedInterfaceMethods[FromTokens]; DocumentStructure.getDocumentKind
• Derived-interface inheritance also exists (INTERFACE(parent), e.g. FormVCRWindowComponent INTERFACE(WindowComponent)) — relevant to item 2's required-method set.
• Overload substrate: [#120 follow-up] DefinitionProvider / MethodHoverResolver / ImplementationProvider still route through legacy selectBestOverload — type-aware findOverloadByArgClassifications not wired in #125 / [#125 follow-up] Pattern A extension: arg-classification wire-up to SELF/PARENT/chained/cross-file paths in Def/Hover/Impl #127 / [#127 follow-up] Cross-file overload resolution must walk MEMBER → PROGRAM → INCLUDE chain (not just current file's INCLUDEs) #128

Priority

Normal — v1 covers the common non-derived case correctly; items 2 & 3 extend coverage and carry more false-positive risk, so they're deliberately deferred.

[msarson]

Re-framed item 1 (2026-06-07, with Mark): the original "cross-file enumeration needs new global substrate" framing was overstated.

In Clarion a CLASS implementing an interface from another .inc must INCLUDE('SomeInterface.inc'),ONCE in its own file (,ONCE optional — include-guard only; resolver keys off the quoted filename). So the interface is reachable by walking the class file's own INCLUDE chain, which MemberLocatorService.findInterfaceInIncludeChain already does. No workspace-wide symbol table needed.

Real remaining work for item 1: (a) an enumerator (existing findMemberInInterface is a single-method lookup; we need to collect all interface methods, reusing the same walk) and (b) migrating validateClassInterfaceImplementation from the sync pass to the async pass with MemberLocatorService threaded in — the bulk of the effort. Items 2 (inherited methods) and 3 (overload discrimination) unchanged. Added a suggested B1–B4 phasing.

[msarson]

v1 shipped on version-0.9.7 (65dae3d).

Important correction: the earlier framing of this issue (and the original #165) assumed a CLASS,IMPLEMENTS(Interface) re-declares the interface methods in its body. Verified against the docs + LibSrc that this is wrong — interface methods are implemented as three-part Class.Interface.Method PROCEDURE defs in the class''s MODULE('x.clw') (or the same PROGRAM/MEMBER file inline). The diagnostic was rebuilt around that model and is conservative (non-derived classes only, skips when interface/impl source unresolvable). Issue body updated; remaining scope is items 2 (derived-class inherited impls) and 3 (overload discrimination).

[msarson]

Item 3 (overload discrimination — substring-slice args) shipped on version-0.9.7 — fix 8206c56, merged 14452f6.

Find-All-References was over-counting overloads when a call passed a substring-slice argument (field[a:b] / field[0:128]) of a STRING-like base: the classifier bucketed it as unknown and the conservative match-all path counted it toward every overload, including the class-typed SetValue(StringTheory).

Root cause / fix: a Phase-A tokenizer probe showed the original "detect the colon" idea is unsound — the tokenizer collapses ident:ident slices into a single token byte-identical to a prefix array subscript arr[LOC:I], so colon-presence can't distinguish a string slice from an array index. The fix uses base-type resolution instead: classifyMultiToken resolves the slice base via the existing resolver seam and infers STRING for any index/slice of a STRING-like base (so it matches SetValue(STRING) only). Non-string array indexing (arr[i]) is left untouched; bare-variable bases only.

Known limitation / follow-up: dotted/prefixed slice bases (SELF.field[a:b], PRE:Field[a:b]) are out of this MVP and not yet wired.

Leaving #181 open — item 2 (derived-class inherited-method implementations) is still outstanding.