Support Smithy IDL 2.0 syntax #18
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds support for some of the new idl syntax for 2.0. Namely it adds support for optional commas, inline IO, and the required syntax sugar. I do not think it is possible for a TextMate grammar to be able to distinguish between a key and a value in every case when there are no pair separators, though I would love to be proven wrong on this. TM grammars are regex-based, but crucially regexes can never match across lines. A regex with a newline in the middle, like `foo\nbar` will NEVER match. This is to allow the highlighter to be able to re-start at any line if parsing failed on a previous line. To work around this somewhat, they allow you to change states with `begin` and `end` regexes. Since these state changes are *regexes* and regexes can't span lines, you can't have a complex end state. So you can't simply say "end after parsing a json-like value". Since we have no other indication that a pair is ended, we can't end a pair state if we enter one. For some context, the way the JSON TM grammar works is by having an effective "value" state which is started by `:` and ended by `,` or `}`. This is what we used to do. Now what we CAN do if we don't care about being 100% accurate in all cases, is try to match the key if it shares a line with the colon. This is the approach I've gone with since I'm willing to bet this will be the case most of the time.
|
I added support for the
|
|
Whoops, forgot mixins! While I was at it I fixed traits within shape definitions and a handful of bad captures.
|
This splits up the innards of shapes and objects since shapes have additional syntax that isn't allowed for generic objects.
mtdowling
requested changes
Nov 15, 2021
This updates the with statment to require brackets. As part of this I had to rethink how shapes worked. Previously we had fairly rigid detection requirements for shapes that did / didn't have bodies and what was allowed in those bodies. Since you can't have two subsequent multiline rules, this presented some extreme difficulties. Instead, the declaration of the shape and the shape body are now split. In practice this means you theoretically have disconnected shape bodies. This is somewhat unfortunate, but ultimately it's fine. This is a syntax highlighter, not a parser. Perfectly enforcing the syntax is a secondary goal to perfectly highlighting it. This isn't uncommon either, you can for instance write "def def def" in a python file and it will be highlighed by vs code just fine even though it won't parse properly.
mtdowling
approved these changes
Jan 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for some of the new idl syntax for 2.0. Namely it adds
support for:
!)= default)withstatementI do not think it is possible for a TextMate grammar to be able to distinguish
between a key and a value in every case when there are no pair separators,
though I would love to be proven wrong on this.
TM grammars are regex-based, but crucially regexes can never match across
lines. A regex with a newline in the middle, like
foo\nbarwill NEVER match.This is to allow the highlighter to be able to re-start at any line if parsing
failed on a previous line. To work around this somewhat, they allow you to
change states with
beginandendregexes. Since these state changes areregexes and regexes can't span lines, you can't have a complex end state. So
you can't simply say "end after parsing a json-like value". Since we have no
other indication that a pair is ended, we can't end a pair state if we enter
one.
For some context, the way the JSON TM grammar works is by having an effective
"value" state which is started by
:and ended by,or}. This is what weused to do.
Now what we CAN do if we don't care about being 100% accurate in all cases, is
try to match the key if it shares a line with the colon. This is the approach
I've gone with since I'm willing to bet this will be the case most of the time.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.