Commit graph

3 commits

Author SHA1 Message Date
Johannes Altmanninger
b5739ddacf Report sub-token error locations again
This fixes a regression about where we report errors:

	echo error(here
	old: ^
	   fixed: ^

Commit 0c22f67bd (Remove the old parser bits, 2020-07-02) removed
uses of "error_offset_within_token" so we always report errors at
token start. Add it back, hopefully restoring the 3.1.2 behavior.

Note that for cases like

	echo "$("

we report "unbalanced quotes" because we treat the $( as double
quote.  Giving a better error seems hard because of the ambguity -
we don't know if quote is meant to be inside or outside the command
substitution.
2021-12-04 16:52:13 +01:00
Fabian Homborg
4ffabd44be Don't add expansion error offset twice
Like the $status commit, this would add the offset to already existing
errors, so

```fish
(foo)
(bar)

something
```

would see the "(foo)" error, store the correct error location, then
see the "(bar)" error, and *add the offset of (bar)* to the "(foo)"
error location.

Solve this by making a new error list and appending it to the existing
ones.

There's a few other ways to solve this, including:

- Stopping after the first error (we only display the first anyway, I
think?)
- Making it so the source location has an "absolute" flag that shows
the offset has already been added (but do we ever need to add two offsets?)

I went with the simpler fix.
2021-09-30 18:09:58 +02:00
Fabian Homborg
6774a514fa Don't set error offset for $status
This would break the location of any prior errors without doing
anything of value.

E.g.

```fish
echo foo | exec grep # this exec is not allowed!

$status

somethingelse # The error might be found here!
```

Would apply the offset of `$status` to the offset of `exec`, locating
the error for `exec` somewhere after $status!
2021-09-30 18:09:58 +02:00