You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is effectively a bug, and the output for 9..9should be:
× Generic Error
╭────
1 │ a = b + c
· ▲
· ╰── Unexpected EOF
╰────
I have a fix for this for the graphical report handler, but haven't successfully ported it over to the narratable handler yet. Ideally I'd like to keep the two in feature parity as much as possible, and I want to hold off on submitting a PR until I've got it working for both. I'll probably have time to take another shot at that later this week.
Longer term, the best path is probably to factor a lot of the duplicated logic between the graphical and narratable handlers into a central place. I have some ideas here, but it's gonna be more work than just fixing this one bug in both places.
I have been trying to model when an unexpected EOF occurs; the current behavior of empty spans in the fancy reporter is a bit puzzling to me.
In the example shown below, a span of
8..9
yields (which is expected):Now my intuition (and AFAIK most tools) would say that the EOF of the string is at
9..9
, setting9..9
as the span yields:Meanwhile,
8..8
yields:I would've expected that
8..8
points beforec
(asc @ 8..9
) and not after the character and9..9
points to where8..8
currently points to.Do you know if this is expected behavior?
Minimal Reproducible Example
The text was updated successfully, but these errors were encountered: