Hello,
I encountered the following issue: when the cleaner encounters a TRANSLATE or CONDENSE statement that uses macro placeholders (e.g., "&1") as arguments, it raises an exception "java.lang.IllegalArgumentException: Supplied TokenType IDENTIFIER unexpected for Token text '&1'; using inferred TokenType OTHER_OP!" (at com.sap.adt.abapcleaner.parser.Token.createForAbap(Token.java:291)).
As the error says, the issue is that "&1" is inferred to be of TokenType OTHER_OP, and not identifier in Token:inferTypeFromAbapToken, which then leads to the exception in Token:createForAbap.
Example:
DEFINE test_rule_macro.
TRANSLATE &1 TO UPPER CASE. " -> error!
TRANSLATE &1 USING 'aabbaABBA'. " -> error!
CONDENSE &1. " -> error!
MOVE &1 to &2. " -> works! (if abap release >= 7.54)
ADD &1 TO &2. " -> works! (if abap release >= 7.54)
END-OF-DEFINITION.
On ABAP versions older than 7.54, this error will also occur for MOVE and ADD (and possibly lots of other rules that I didn't try out), because then this else branch will be entered.
In summary, the issue will arise for any call to Token.createForAbap() where the provided text starts with "&" and the provided type is IDENTIFIER. I guess a (maybe not so pretty) solution would be coding an exception for texts starting with "&" in Token:createForAbap() [I could provide a pull request for that].
Best regards,
Pascal
Hello,
I encountered the following issue: when the cleaner encounters a TRANSLATE or CONDENSE statement that uses macro placeholders (e.g., "&1") as arguments, it raises an exception "java.lang.IllegalArgumentException: Supplied TokenType IDENTIFIER unexpected for Token text '&1'; using inferred TokenType OTHER_OP!" (at com.sap.adt.abapcleaner.parser.Token.createForAbap(Token.java:291)).
As the error says, the issue is that "&1" is inferred to be of TokenType OTHER_OP, and not identifier in Token:inferTypeFromAbapToken, which then leads to the exception in Token:createForAbap.
Example:
On ABAP versions older than 7.54, this error will also occur for MOVE and ADD (and possibly lots of other rules that I didn't try out), because then this else branch will be entered.
In summary, the issue will arise for any call to Token.createForAbap() where the provided text starts with "&" and the provided type is IDENTIFIER. I guess a (maybe not so pretty) solution would be coding an exception for texts starting with "&" in Token:createForAbap() [I could provide a pull request for that].
Best regards,
Pascal