[red-knot] Incorrect syntax error persistent in playground

[sharkdp]

This is something that happened to me a few times. It's always the same situation. I add a return type annotation by typing -> … after a function definition, and then I'm left with a syntax error that shouldn't be there:

How to reproduce:

• Go to https://playknot.ruff.rs/ffc63887-bdf3-4471-a4be-097a2f047e2b
• Add an incorrect return annotation (by typing), for example: -> str
• Observe incorrect syntax error Expected ':', found '-' (invalid-syntax)

Seems to be related to there being another diagnostic as well. If you type -> int, it works fine. If you do random other changes to that file, the error often goes away. For example, if you select all text, cut it, and paste it back in, the error is gone.

[MichaReiser]

It's very specific about adding - when typing the return type. The problem is that the parser generates 6(!) diagnostics, all starting at the very same position

[
  {
    "id": "invalid-syntax",
    "message": "Expected ':', found '-'",
    "severity": 2,
    "range": {
      "__wbg_ptr": 4924664
    },
    "textRange": {
      "__wbg_ptr": 4924816
    }
  },
  {
    "id": "invalid-syntax",
    "message": "Invalid annotated assignment target",
    "severity": 2,
    "range": {
      "__wbg_ptr": 4924840
    },
    "textRange": {
      "__wbg_ptr": 4924872
    }
  },
  {
    "id": "invalid-syntax",
    "message": "Expected an expression",
    "severity": 2,
    "range": {
      "__wbg_ptr": 4924896
    },
    "textRange": {
      "__wbg_ptr": 4924928
    }
  },
  {
    "id": "invalid-syntax",
    "message": "Expected an expression",
    "severity": 2,
    "range": {
      "__wbg_ptr": 4924952
    },
    "textRange": {
      "__wbg_ptr": 4924984
    }
  },
  {
    "id": "invalid-syntax",
    "message": "Unexpected indentation",
    "severity": 2,
    "range": {
      "__wbg_ptr": 4925008
    },
    "textRange": {
      "__wbg_ptr": 4925040
    }
  },
  {
    "id": "invalid-syntax",
    "message": "Expected a statement",
    "severity": 2,
    "range": {
      "__wbg_ptr": 4925064
    },
    "textRange": {
      "__wbg_ptr": 4925096
    }
  }
]

This seems like something we should improve in the parser but, obviously, this shouldn't break the playground.

The reason this breaks the playground is because I use {startLine}:{startColumn}-{id} as a unique identifier, which obviously isn't as unique as I thought...