REPL: Sync the ^C sweep test on the evaluation result (#63295)
* REPL: Sync the ^C sweep test on the evaluation result
In julia-pr build 2541 this test hung at the `Cancelled all in-flight
work.` read and was hard-killed after the 900s timeout, on both
i686-linux-gnu and aarch64-linux-gnu:
https://buildkite.com/julialang/julia-pr/builds/2541#01a0aee0-fc2e-43c8-a079-4161fe774fa9
The sweep had in fact thrown - a `CancellationTokenSource` walk reached
freed memory, since fixed by #63234 - and the keymap logs and swallows
that, so the message never came and the read blocked forever.
The test widened that window. Its stand-down step types `1` and reads
until `julia> `, but the `^C` handler that armed the sweep ends in
`transition(s, :reset); refresh_line(s)`, so a prompt is already sitting
unread in the pipe and the read matches that instead, before `1` has
been processed at all. The step meant to stand the arm down is never
waited for, and everything after it races the evaluation. Looping the
block under `-t1` hit the freed-memory error 5 times in 600 iterations
as written, and once in 900 with the read below.
Communicate through a result value, as the rest of the block does; the
concatenation keeps the needle out of LineEdit's echo of the typed
characters.
Assisted-by: Claude Code (Opus 5)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* REPL: Reword the double-^C test comments
Review of this test found its comments hard to read: they lean on
invented vocabulary ("arms the sweep", "stands the arm down", "session
epoch") instead of saying what each key press does. Describe the
behaviour in plain terms, and spell out why the awaited results are
written as concatenations. The marker expression is renamed to match.
Assisted-by: Claude Code (Fable 5.1)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
