Custom operators are obtuse and restrictive #5
Labels
bug
Something isn't working
error-for-valid-code
The grammar causes a parsing error for some code that should parse
missing-language-feature
A Swift language feature is not supported by the grammar
top-repos-error
A failure that shows up in one of the top repos parsed by the `top-repos` script
Comments
alex-pinkus
added
bug
|
The biggest impact I'm aware of here is that the |
alex-pinkus
added
the
top-repos-error
alex-pinkus
added a commit
that referenced
this issue
Nov 7, 2021
We still need to move the custom operator logic to the scanner, but that's a lot of complexity, and it's still unclear how to do that without a lot of breakage. Instead of doing that now, we just special case handling of `<` (which is what was tripping up a lot of Carthage files). With this change, #5 will no longer be a top-repos-error, even though it will still be a valid bug.
alex-pinkus
removed
the
top-repos-error
|
So it should follow the "Grammar of operators" from https://docs.swift.org/swift-book/ReferenceManual/zzSummaryOfTheGrammar.html? If so, from what I see, regexes will suffice |
|
It should end up more or less equivalent to that, but there’s some special casing required for cases like the ones in #41, where an operator ending in a |
|
Unfinished PR at #151 |
|
For posterity: the top-repo error here currently is at |
alex-pinkus
added
the
top-repos-error
alex-pinkus
added a commit
that referenced
this issue
Sep 4, 2022
Custom operator rules are better expressed as conditions to track in `eat_operator` vs a series of impenetrable regexes. Also requires a fix for an undiscovered bug where `x[...]!` was not considered to be a legal target for an expression. Since the old logic allowed `+=` to be a "custom operator", we were covering up for that failure by interpreting `x[...]! += y` as a custom infix expression. Fixes #5
alex-pinkus
added a commit
that referenced
this issue
Sep 4, 2022
Custom operator rules are better expressed as conditions to track in `eat_operator` vs a series of impenetrable regexes. Also requires a fix for an undiscovered bug where `x[...]!` was not considered to be a legal target for an expression. Since the old logic allowed `+=` to be a "custom operator", we were covering up for that failure by interpreting `x[...]! += y` as a custom infix expression. Fixes #5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, a custom operator must match one of five weird regexes that have subtle differences and are each of dubious necessity. There are many legitimate character combinations that should be legal, but are not, including anything using advanced unicode (related: unicode identifiers bug).
What this really points to is that custom operators should just be defined as
externals, where we can define the rules inscanner.cand make it look something like what the official grammar says it should be.The text was updated successfully, but these errors were encountered: