Cogen: Simplify COPY(instance) to not transfer EXTEND et al.

[willend]

Free-form text area

Please describe what your PR is adding in terms of features or bugfixes:

The work in this PR starts from the discussions in #2621 and

• re-implements COPY(instance) without EXTEND.
• For symmetry, transfer of all of WHEN, GROUP, JUMP and metadata is also dropped.
• The warning that "EXTEND would be overwritten" has been suppressed.
• An ADR record is included in the PR.

---

Declaration of use of AI-tools

• Please add a checkmark here if you used AI-tools during the work for this contribution
• Furter, please describe how / where and for what the tools were used:

AI was used to compile the attached spreadsheet that shows very limited effect (non-tested monitors in ILL_H5 and ILL_H5_new) the changes in the PR are estimated to have. (Feedback from the AI is visible on #2621 and is copied in below.)

copy_survey 1.csv

It turns out the actual risk pool is very small.

I re-walked every .instr file in component-declaration order, resolved each COPY(source) / COPY(PREVIOUS) / COPY(PREVIOUS(n)) back to its source (including chains — a copy of a copy), and compared "effective value today" vs. "effective value with inheritance removed" for GROUP, JUMP, WHEN, METADATA. EXTEND is reported separately and excluded from the risk count per your note that its silent-copy path is already broken.

Result — real behaviour-change risk is essentially isolated to one pair of files:

keyword	McStas files at risk	McXtrace files at risk
GROUP	0	0
JUMP	0	0
WHEN	2	0
METADATA	0	0

The two flagged files are ILL_H5.instr and ILL_H5_new.instr (near-duplicate instruments), 3 instances total. Concretely, in ILL_H5.instr line 946:

COMPONENT H511_mirror_outdXY = COPY(H511_mirror_ReflectXY)(options="dx limits=[-2 2], dy limits=[-2 2]")

H511_mirror_ReflectXY carries WHEN flag==1, and this copy restates no WHEN of its own — so today it silently only fires when flag==1; once inheritance is dropped it will fire unconditionally, double-counting into that monitor. (A sibling copy in the same block, H511_mirror_TransmitXY, is fine because it does write its own WHEN flag==2.) The same pattern repeats once in ILL_H5.instr and twice in ILL_H5_new.instr.

GROUP and JUMP came back at zero risk because, looking at how they're actually used across the codebase, authors always restate GROUP explicitly on every group member and always give JUMP its own target — nobody appears to rely on inheriting those silently. METADATA is zero simply because no instance anywhere in either tree writes an instance-level METADATA clause at all yet.

One methodological note: the resolver found zero unresolved COPY sources in either tree (every COPY target was defined earlier in the same file), so this isn't a partial estimate hedged by missing data — it's a complete, source-order resolution across both codebases, modulo the usual caveats around %include-composed instruments and the rare REMOVABLE prefix (23 occurrences repo-wide).

---

Development OS / boundary conditions

Please describe what OS you developed and tested your additions on, and if any special dependencies are required:

---

PR Checklist for contributing to McStas/McXtrace

For a coherent and useful contribution to McStas/McXtrace, please fill in relevant parts of the checklist:

• My work touches the code-generator in mccode/src

  • I have added reasoning and documentation for the change through an ADR record in our GRAMMAR section (doc/GRAMMAR/ADR-records/ADR_20260904_COPY_INSTRUMENT.md)
  • I am attaching test output in the comments

• My PR is meant to fix a specific, existing issue

  • I have indicated the issue number here: Instance COPY empty-EXTEND bug -> feature #2621
  • I have added documentation for the fix and possible side effects

• My contribution contains something else

  • Explanation is added in free form text above or below the checklist

---

[willend]

A testsuite-output for McXtrace can be found here - all is green:
https://tmp.mccode.org/PR2627/mcxtrace-nightly/mcxtrace-nightly_output.html

[willend]

McStas testsuite-output is available here: https://tmp.mccode.org/PR2627/mcstas-nightly/mcstas-nightly_output.html

Issues:

• False positive compilation problem across platforms - this can be ignored, presents itself like this in the log on all test instances in the comparison run:

ESS_butterfly_MCPL_test                     : COMPILE ERROR using:
mcrun --mpi=1  --verbose -c -n0 ESS_butterfly_MCPL_test > compile_stdout.txt 2>&1 

• The remaining issues are all mcstas-antlr related:
  • Overall status FAILED! One or more tests errored (1 compile errs / 1 runtime errs / 3 values off (compile issue is the above false postive)
  • RTP_Laue : 3.41 [val: 1722.75 / 179284.0 = 1 %] <--- BIG DISCREPANCY?? (directly relates to COPY+EXTEND handling - should be solved on mccode-antlr main - i.e. ✅ )
  • SEMSANS_instrument : 1.40 [val: 0.0 / 2.87073e-09 = 0 %] <--- BIG DISCREPANCY?? Requires separate investigation - no use of COPYorEXTEND`
  • BTsimple : 2.17 [val: -1 / 75.4758 = -1 %] + !! RUNTIME FAILURE - see run_stdout_1.txt !! <--- BIG DISCREPANCY?? includes a "post-processing monitor" in the FINALLY of the instr, perhaps something prevents this from functioning in mcstas-antlr?

[willend]

Failure-state on last commit corresponds to mccode-dev/mccode-antlr#334 (mccode-dev/mccode-antlr#333 is also relevant but not directly reflected in commit-triggered test)