-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support modifiers + patterns #38
Support modifiers + patterns #38
Conversation
+ also add a `support.dart` for test files that is excluded from testing to avoid too much noise in the test files.
Oh, FWIW the highlighting above is not what VS Code users will generally see, because Semantic Tokens will be layered over the top, but it's what they'll see until those arrive, roughly what they'll see with a theme that doesn't support semantic tokens, or this grammar used elsewhere (other editors, DevTools, GitHub, etc.). |
Looks great! re:
Perhaps track this as an issue? I didn't look into the grammar, but perhaps we could use more contextual info to eliminate false positives? For example, a function would need to be proceeded by |
@devoncarew I just snook in a fix for this. I looked at the code and found that this seemed bogus - we were already handling parens, but had this extra code to handle where they didn't exist (basically getters). This was inconsistent with the colouring we get from semantic tokens (where getters are not coloured like functions), so I've removed it. The changes in goldens are the ones we want ( |
Sounds great - thanks for the update. |
This expands the tests to include some class modifiers and patterns. It also adds a new file 'support.dart' that is excluded from the golden tests as a place to put some declarations that would otherwise add lots of noise to the test files.
The first commit adds the new test files and generates goldens without any highlighting changes, and the second commit has the changes to syntax + results in goldens.
From a quick scan over these examples (which I copied from the feature spec, but I don't know if I've covered everything), things generally look ok with the exception of these switch expressions:
We have a rule that assumes that
foo => bar
meansfoo
is a function, so it gets coloured yellow here. This is incorrect here. Given the way this syntax works is very simple and not a full parser, I don't know if it's going to be simple to handle this, but while I figure that out I thought it was worth landing the basic support so keywords are recognised.Here's an larger example of how the highlighting currently looks in VS Code:
@devoncarew @jwren