Throw ERRBadAwait instead of ERRnoSemic if applicable

[ShortDevelopment]

Issue

It might happen that a developer forgets to declare a function as async but still uses await as a keyword.
In this case the CC parser will just display a ERRnoSemic as seen in #5103.

Changes

According to the proposal of @rhuanjl in #5103 (comment) the parser now checks if the previous token was a tkID equal to await.
In that case the parser throws a ERRBadAwait.

---

Fixes #5103

[rhuanjl]

Thanks for the contribution, it would be nice to see this changed.

Unfortunately the test fails look legitimate to me, (as in this appears to have introduced a new bug) if you can work out what's gone wrong that would be great, if not I'll try and investigate on Monday or Tuesday.

[ShortDevelopment]

@rhuanjl Comparing the CI output of a PR with "no code" and mine it seems like the failing tests might be unrelated to the changes in this PR

• https://cirrus-ci.com/task/6543904518963200
• https://cirrus-ci.com/task/6730463671222272

Both failed with

Total: passed 1382, failed 630

[rhuanjl]

@rhuanjl Comparing the CI output of a PR with "no code" and mine it seems like the failing tests might be unrelated to the changes in this PR

• https://cirrus-ci.com/task/6543904518963200
• https://cirrus-ci.com/task/6730463671222272

Both failed with

Total: passed 1382, failed 630

Seems you were right, CI is sorted now, this PR looks good though I'd ideally not like to introduce the TS comments to our codebase.

[ShortDevelopment]

@rhuanjl Comments are removed

Seems you were right, CI is sorted now

It's still a bit scary to have CI failing randomly

[rhuanjl]

@rhuanjl Comments are removed

Seems you were right, CI is sorted now

It's still a bit scary to have CI failing randomly

I think it was an issue ages ago that's been fixed in the meantime...

I'll gain additional confidence of that if it passes again now having already passed once before you removed the comments.