Raw string interpolation has proven to be a bit trickier to
implement, since we don’t want to treat `#` as a delimiter
(since it’s used in so many other ways in Swift, for example
for `#if`, `#available`, etc.).
This patch contains a “quick fix” for supporting interpolated
raw strings that contain a single expression per interpolation.
A proper fix should be developed as soon as possible, but this
unblocks using Splash to highlight most raw string interpolated
code samples, for now.
This patch fixes syntax highlighting for any comments that begin with
a delimiter, which would previously prevent the comment’s leading token
from being parsed correctly. The fix is to prevent slashes to be merged
with any other delimiter, except for other slashes and asterisks.
This patch fixes highlighting of any type declarations that follow
a comment which was ended with a punctuation character. The fix is
to only look at previous tokens on the same line when determining
whether a given token is a keyword.
This patch makes Splash correctly highlight strings in which a value
is interpolated next to a delimiter character. The fix is to enable
each `Grammar` implementation to decide whether two tokens should be
*merged*, which in turn enables `SwiftGrammar` to veto that string
interpolation delimiters should be merged with their predecesor.
- Don’t highlight what *could* be a static method call using
the `dotAccess` style, only highlight tokens that are either
value-less enum cases or static properties.
- The exception to the above rule is within `switch` statements,
in which even call-like tokens are assumed to be enum cases.
- Highlight calls to `.init()` as keywords, for consistency
with other `init` usages.
This patch fixes syntax highlighting for types and functions which names
begin with an underscore. Previously these entities would be treated as
plain text, but now they’re highlighted correctly as either types or
function calls.
This patch fixes syntax highlighting for when shorthand closure
arguments ($0, $1…) are interpolated into a string literal. The
fix is to no longer treat “$” as a delimiter, which should help
solve similar issues that might be encountered in the future as
well.
This patch makes Splash correctly highlight closure argument
shorthands (`$0`, `$1`, etc.), while also making the logic for
detecting a function call a bit simpler.
This makes Splash correctly highlight key paths that are passed as arguments
to a function, especially when there’s no external parameter label for that
argument.
This patch makes Splash correctly highlight nested closures marked with
the `@escaping` attribute. The fix is to start treating `@` like a proper
token, rather than as a delimiter.
This change makes Splash capable of highlighting Swift 5 raw strings,
although it’s currently limited to single line string literals. Support
for multi-line literals will be added in a future commit.
This change enables Splash to highlight multi-line comments that begin
with two asterisks, rather than just one. A test has also been added to
verify that documentation-style multi-line comments with an asterisk on
each line are also highlighted correctly.
This change adds support for three pre-processors that can appear in
function delcarations: `#file`, `#line` and `#function`. They’re not
highlighted as pre-processors, but rather as keywords, to match the
way Xcode treats them.
Normally, we don’t want Splash to contain too many special cases for
individual symbol names — but the `XCTAssert` family of functions are
so common that it warrants it. The problem is that Splash would currently
highlight those functions as types, since they are capitalized, which
has now been changed to function calls instead.
This patch makes Splash correctly highlight associated types within
protocol declarations. Like other declarations, typed declared using
the `associatedtype` keyword should not be highlighted.
Previously, the last protocol would be treated as a function call (Splash
thought it was a call with trailing closure syntax, rather than the opening
of a type definition). This patch fixes that by verifying that the code
checking for constraints inside a generic type definition is in fact looking
at a generic, rather than something else.
Swift enables the use of keywords as function names, and we want those
to be treated as plain text (like other function names) rather than as
keywords. Some keywords require escaping using back-ticks, and this
patch accounts for both of those variations.
This patch fixes syntax highlighting for the following scenario:
```
Type<GenericType>.call()
```
Highlighting generic types is especially tricky, since we want them to
be highlighted when appearing at the call site, like above - but we don’t
want to highlight them when they are being declared. Hopefully with this
fix all/most edge cases are covered.
