Row types in where clause signatures break highlighting for the clause

[nwolverson]

A row type (foo :: Bar) included in a type signature of a function in a where clause seems to be breaking highlighting for the rest of the where block (in vscode). The same issue is not appearing at the top level, I think.

module TestHighlight where

x = 3
  where
  good :: { x :: Int } -> Int
  good _ = y + z

  something = good

z = 4
  where
  bad :: Record (x :: Int) -> Int
  bad _ = y + z

  something = ugly

The issue goes away if I go back to vscode extension back in 2021 (which I assume I was somehow on already - our code has a bunch of large where blocks and it is impossible to miss), possibly introduced around here a28890a

[wclr]

This is caused by row_types rule in function_type_declaration. This rule is quite stupid now.

[nwolverson]

Thanks, that's helpful

[wclr]

Though, this (fix with indentBlockEnd) breaks some other cases with row types.

I need to revisit this, it seems I used rough and ad-hoc tricks to make row types work and there are still issues.

[nwolverson]

This is nested row types that are breaking specifically there?

Of course this mostly-line-based regex highlighting is a losing game in the end, but maybe it can be fixed.

[wclr]

This is nested row types that are breaking specifically there?

No, it is not about nested, it is row lables "c", "d" here are not hightlited properly.

[nwolverson]

By nested I mean the c/d labels come after a nested row type, which I assumed was somehow a problem.

This actually looked fine for me because my theme doesn't distinguish record fields from the general variable in a type declaration, but I see the scopes are missing

meta.record-field.type-declaration.purescript
meta.type.row.purescript

If you think you can come up with something better, I will leave you to that, but I think the primary distinction of "type-signature or not" is more important if we have to choose.

My only thought is that you could say "either something starting on a newline or finishing the row on the same line", combining the 2 existing attempts at this rule

[wclr]

If you think you can come up with something better, I will leave you to that, but I think the primary distinction of "type-signature or not" is more important if we have to choose.

I think your current fix is ok and probably more important for now if you want to release the fixed version.

I will take a look into it closer later and see what can be done about it, this should be revisited and probablly redesined a bit.