Add parser diagnostics about END statement

MarkusAmshove commented 4 months ago

This adds around 132 diagnostics for us.

Most of them are No source code allowed after the END statement, because we don't parse END TRANSACTION yet and it gets recognized as END-Statement.

The others are modules using . as END 🙄

I just took a sample size to look through, but those two are the ones I've in that sample size.

We should get rid of both by supporting the actual stuff. . (SyntaxKind.DOT) could be added as IEndNode, so that we don't have to check for both. If an analyzer wants to do check the end statement for code style, it can hook into IEndNode and just check the token. No need to have different nodes.

If you want to do either of those, or both, you can implement them in this PR or in new ones. I'd leave this open until we fix them. I can also do one of those or both, you can decide :)

Claes65 commented 4 months ago

This adds around 132 diagnostics for us.

Most of them are No source code allowed after the END statement, because we don't parse END TRANSACTION yet and it gets recognized as END-Statement.

The others are modules using . as END 🙄

I just took a sample size to look through, but those two are the ones I've in that sample size.

We should get rid of both by supporting the actual stuff. . (SyntaxKind.DOT) could be added as IEndNode, so that we don't have to check for both. If an analyzer wants to do check the end statement for code style, it can hook into IEndNode and just check the token. No need to have different nodes.

If you want to do either of those, or both, you can implement them in this PR or in new ones. I'd leave this open until we fix them. I can also do one of those or both, you can decide :)

Interesting ;) If you can do the SyntaxKind.DOT thing, then I can support ET. Or if you have time, you can do both. I won't be able to work on this until Monday.

MarkusAmshove commented 4 months ago

I've added both things and don't get any new diagnostic anymore :)

Claes65 commented 4 months ago