Skip to content

Incorrect highlighting of parse errors in else body #14784

Closed
@ysthakur

Description

Describe the bug

When the else body of an if expression has a parse error, the wrong span is highlighted in red. In fact, it seems like only the last span is highlighted in red, no matter what.

How to reproduce

You can trigger this issue by typing if true { 0 } else echo <bad expr>... <good expr> into the REPL. <bad expr>... is one or more expressions with parse errors in them (e.g. $nonexistent or ([] + "foo"), separated by spaces. <good expr> is something without any parse, e.g. 2.

Only the last span, <good expr>, will be highlighted red, and there will be no highlighting for the stuff before it (echo <bad expr>...) at all.

For example, you can use if true { 0 } else echo $foo 2. The 2 is highlighted rather than $foo, the nonexistent variable.
image

It looks like when the parser realizes that $foo is undefined, instead of creating a garbage span for $foo, it creates one for 2.

> ast -f "if true { 0 } else echo $foo 2"
╭─#─┬─content─┬───────shape────────┬──────span──────╮
│ 0 │ if      │ shape_internalcall │ ╭───────┬───╮  │
│   │         │                    │ │ start │ 0 │  │
│   │         │                    │ │ end   │ 2 │  │
│   │         │                    │ ╰───────┴───╯  │
│ 1 │ true    │ shape_bool         │ ╭───────┬───╮  │
│   │         │                    │ │ start │ 3 │  │
│   │         │                    │ │ end   │ 7 │  │
│   │         │                    │ ╰───────┴───╯  │
│ 2 │ {       │ shape_block        │ ╭───────┬────╮ │
│   │         │                    │ │ start │ 8  │ │
│   │         │                    │ │ end   │ 10 │ │
│   │         │                    │ ╰───────┴────╯ │
│ 3 │ 0       │ shape_int          │ ╭───────┬────╮ │
│   │         │                    │ │ start │ 10 │ │
│   │         │                    │ │ end   │ 11 │ │
│   │         │                    │ ╰───────┴────╯ │
│ 4 │  }      │ shape_block        │ ╭───────┬────╮ │
│   │         │                    │ │ start │ 11 │ │
│   │         │                    │ │ end   │ 13 │ │
│   │         │                    │ ╰───────┴────╯ │
│ 5 │ else    │ shape_keyword      │ ╭───────┬────╮ │
│   │         │                    │ │ start │ 14 │ │
│   │         │                    │ │ end   │ 18 │ │
│   │         │                    │ ╰───────┴────╯ │
│ 6 │ 2       │ shape_garbage      │ ╭───────┬────╮ │
│   │         │                    │ │ start │ 29 │ │
│   │         │                    │ │ end   │ 30 │ │
│   │         │                    │ ╰───────┴────╯ │
╰───┴─────────┴────────────────────┴────────────────╯

Expected behavior

I would expect the span for $foo to be highlighted red, nothing else. I would also expect both echo and 2 to be highlighted normally, although that's not as much of a priority.

Configuration

key value
version 0.101.0
major 0
minor 101
patch 0
branch
commit_hash
build_os linux-x86_64
build_target x86_64-unknown-linux-gnu
rust_version rustc 1.83.0 (90b35a623 2024-11-26) (built from a source tarball)
cargo_version cargo 1.83.0 (5ffbef321 2024-10-29)
build_time 1980-01-01 00:00:00 +00:00
build_rust_channel release
allocator mimalloc
features default, sqlite, trash
installed_plugins

Metadata

Assignees

No one assigned

    Labels

    🐛 bugSomething isn't workingparserIssues related to parsingsyntax-highlightingBugs or performance issues with the syntax highlighting logicunhelpful-errorThe error message you observe is not helpful to identify the problem

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions