feat(objectscript): InterSystems IRIS ObjectScript language support

[isc-tdyar]

What does this PR do?

Adds ObjectScript (InterSystems IRIS / Caché) as a supported language, per the discussion in #462.

ObjectScript powers large healthcare, finance, and enterprise systems and has no support in CBM (or most code-graph tools). This PR makes those codebases indexable and resolves the call-dispatch patterns that are structurally invisible to text search.

Refs #462

⚠️ Read first — grammar is a separate dependency

Per your note on #462, this PR contains only the CBM source changes — not the vendored grammar. The two tree-sitter grammars come from intersystems/tree-sitter-objectscript (MIT licensed, maintained by the language vendor): objectscript_udl (.cls) and objectscript_routine (.mac/.inc/.rtn/.int).

Consequence: the build will not link until the grammar is vendored at internal/cbm/vendored/grammars/objectscript_udl/ and …/objectscript_routine/ — it fails on the missing tree_sitter_objectscript_udl() / _routine() symbols. CI will be red until then. That is intentional, matching your plan to audit and vendor the grammar independently. The grammar shims (grammar_objectscript_*.c) that declare those factories are included — only the generated parser.c/scanner.c are omitted.

What's in the PR

Definition extraction — Class, Method, ClassMethod, Property, Parameter, Index, Trigger (with body text), XData, Storage, Query members → graph nodes; base classes from the Extends clause.

Four call-dispatch patterns (all resolved statically at index time):

Pattern	Example	Notes
Explicit cross-class	##class(Pkg.Class).Method()	from AST
Relative-dot self-call	..Method()	the dominant intra-class form; large impact on CALLS completeness
Macro expansion	$$$Macro	resolved via a per-project table built from .inc files
Type inference	Set x = ##class(P).%New() … x.Save()	from %New/%OpenId + declared return types

Ensemble production topology (pass_ensemble_routing.c) — EnsembleItem nodes per production component and ROUTES_TO edges resolved from ProductionDefinition XData; plus WorkMgr .Queue("##class(X).method") dispatch. All static — no live IRIS instance required.

Two design points for your review

1. Public API unchanged. ObjectScript needs two per-project tables (a $$$macro table and a method-return-type table) that single-file extraction can't build alone. Rather than widen the public cbm_extract_file() signature (which would ripple NULL, NULL through every call site), I added an internal cbm_extract_file_ex() that carries the tables; cbm_extract_file() is a thin wrapper that delegates with NULL, NULL. Only the pipeline passes that build the tables call _ex.

2. Extension collisions with Apex and BitBake (both added since I started this work). .mac/.int/.rtn map to ObjectScript routine directly. The two collisions are resolved by content sniffing, following the existing cbm_disambiguate_m() (.m MATLAB-vs-ObjC) pattern, and default to the existing language on any doubt so neither Apex nor BitBake regresses:

   • .cls (vs Apex): a Class <Uppercase…> header line → ObjectScript UDL, else Apex. Edge case: a .cls whose Class line sits beyond the first 4 KB (e.g. a very large license banner) would fall through to Apex.
   • .inc (vs BitBake): a ROUTINE <Uppercase> header or an ObjectScript preprocessor directive (#define / #def1arg / #;) → ObjectScript routine, else BitBake. (#define/#def1arg never collide with BitBake, which uses # only for # comment.)

   These are the spots most likely to need your input — happy to adjust the heuristics or the generalization however you prefer.

EnsembleItem label (your Q2 on #462)

I used a domain-specific EnsembleItem node label and ROUTES_TO edge type. If you'd prefer a generic label (ServiceComponent / WorkflowNode) with ensemble_item as a property, I'm glad to rename — just let me know before merge.

Tests

tests/test_extraction.c gains the ObjectScript suite: UDL class/method extraction, all four dispatch patterns, Ensemble topology parsing, macro expansion, trigger body text, and Export-XML transcoding. The Export-XML transcoder tests are grammar-independent and pass today; the grammar-dependent tests pass once the grammar is vendored. No other test files are touched.

Scope / roadmap

This PR is the foundation. If it's well received, two separate follow-up PRs would complete the story (each with its own issue): (a) cross-version version_tag + diff_versions, and (b) ObjectScript-tuned semantic embeddings. They're deliberately excluded here to keep this reviewable.

Checklist

• Every commit is signed off (git commit -s) — DCO
• Tests pass locally (make -f Makefile.cbm test) — passes once the grammar is vendored; see note above
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by tests

[isc-tdyar]

@DeusData - pinging you as I think this is ready for review :) If not, please lmk what you think needs to happen.

[DeusData]

Thanks @isc-tdyar will check ASAP

[DeusData]

Good news, @isc-tdyar — the ObjectScript grammars are now vendored on main (PR #590): internal/cbm/vendored/grammars/objectscript_udl/ and objectscript_routine/, from intersystems/tree-sitter-objectscript @ a7ffcdf (MIT, ABI 15).

Please rebase this PR onto latest main — your grammar_objectscript_{udl,routine}.c shims will now resolve the #include "vendored/grammars/objectscript_{udl,routine}/{parser,scanner}.c", so the build will link and CI should go green (the grammar-dependent extraction tests included).

One vendoring note (no action needed on your side): each scanner.c's upstream #include "../../common/scanner.h" was repointed to a per-directory objectscript_common.h, because this repo's shared vendored/common/scanner.h already belongs to the cfml/fsharp grammars. It's self-contained, so your shims don't need to change.

Once it's rebased and green, I'll review the extraction code and we can land it. Thanks for your patience on the grammar-vendoring step — that was on us to do.

[isc-tdyar]

This PR for ObjectScript language support is fully green across all platforms and ready for maintainer review @DeusData :)

[DeusData]

Thanks for the ObjectScript work. Since this PR is expected not to link until the grammars are vendored, we should not merge it as-is. Please either split this into a source-only design/review PR that does not wire the build, or include the independently reviewed vendored grammar provenance so CI can be green. The Makefile and vendored scanner changes will need maintainer review before merge.

[tom-dyar]

Hi @DeusData — just to clarify the current state: the grammars are already vendored, in your PR #590 on main — that's exactly what your Jun 23 comment asked us to wait for. We rebased onto that main on Jun 24, and CI has been fully green since then (all 13 checks pass across Ubuntu/ARM/macOS/Windows).

The commit message on this PR was written before #590 landed and says "grammars not vendored" — that's now out of date. The build links, the grammar-dependent extraction tests run, and the scanners are the vendored copies from internal/cbm/vendored/grammars/objectscript_{udl,routine}/.

So no split needed — the concern in your latest comment was the pre-rebase state. Happy to update the commit message to reflect that the grammars are now present if that would help clarify things.

[DeusData]

Thanks for clarifying — you’re right that my last comment was based on the stale pre-rebase state/commit text. I verified the current CI is green and the grammar-vendoring concern no longer applies.

The current repo-level blocker I see is GitHub marking this PR as conflicting. Please resolve the merge conflicts, and if convenient update the stale commit/PR wording so reviewers don’t trip over the old “grammars not vendored” state. After that this can move back to extraction-code review.

[isc-tdyar]

@DeusData - I just rebased to get the latest from upstream, so this should be in good shape now to merge, no conflicts showing for me. Thanks, kindly!