search

PLC-lang / rusty

Structured Text Parser and LLVM Frontend
GNU Lesser General Public License v3.0
215 stars 53 forks source link

Treat keywords as identifiers if they are in the Identifier's place #249

Closed ghaith closed 3 years ago

ghaith commented 3 years ago

Is your feature request related to a problem? Please describe. ~Keywords such as CLASS or OVERRIDE are new, and could be used as normal identifiers in some cases (oscat uses an OVERRIDE method)~ We currently cannot define variables with the names E<Number> as this pattern is resolved for exponents. We should allow these.

Describe the solution you'd like ~As a default strategy, if we are expecting an Identifier at a certain position, then also accept any token that is marked as Keyword (but maybe not those marked as Literal or Operator) and use the slice() as the identifier.~ ~We could probably add a warning about the use of a keyword as an identifier.~ Exponents should also be allowed as identifiers (E0), we could solve this on the lexer side and free the "Exxx" pattern for the parser.

The following code should parse

FUNCTION foo : INT
VAR_INPUT
  E0 : INT;
END_VAR
END_FUNCTION

Describe alternatives you've considered ~We could require the user to change his code, but I think the proposal above is reasonable~

Additional context ~This affects our recovery strategies.~

ghaith commented 3 years ago

I'm changing the scope of the issue to only support the exponents. Supporting all keywords would be a lot of (mostly) useless work and the result might be confusing. At some point, we might want to introduce some strict flags to support only a version of the standard, and we could rethink the issue there.