abaplint
suggestion: exclude non-abap language parts from linter
according to https://syntax.abaplint.org/#/abap/statement/MethodImplementation, a class method can be implemented using another language, e.g. SQLSCRIPT.
As the ABAP linter cannot interpret the code and throws a lot of unnecessary problem messages.
Obviously, it would be great to include these languages in the linter, but that does not seem feasible.
So I' suggest to exclude these code parts from the linter and treat them like some kind of comment.
BR, Jan
Example:
METHOD session_context BY DATABASE FUNCTION
FOR HDB LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY.
RETURN
SELECT
port,
connection_id,
key AS key_,
value,
section,
host
FROM sys.m_session_context;
endmethod.
they do identify as NativeSQL, so need to exclude those "statements" from the rules
I've tested with standalone 2.113.68. The linter does not exclude the native SQL. You can see it from this slightly enhanced code snippet - it's still throwing an error because of the colon:
CLASS cl_global_func DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
INTERFACES: if_amdp_marker_hdb.
CLASS-METHODS get_dummy FOR TABLE FUNCTION /test/abc.
ENDCLASS.
CLASS cl_global_func IMPLEMENTATION.
METHOD get_dummy BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY.
RETURN
SELECT dummy FROM sys.dummy WHERE dummy = :var;
ENDMETHOD.
ENDCLASS.
You might notice that it does not recognize the end of "Native SQL" correctly:
=> Both the "ENDMETHOD." and the "ENDCLASS." are marked as "Native SQL"...
That last post came from another example where I put double quotes around the schema name, and as they are recognized as the beginning of a comment, the rest doesn't parse well:
REPORT zfoobar.
CLASS lcl_global_func DEFINITION.
PUBLIC SECTION.
INTERFACES if_amdp_marker_hdb.
CLASS-METHODS get_dummy FOR TABLE FUNCTION /test/abc.
ENDCLASS.
CLASS lcl_global_func IMPLEMENTATION.
METHOD get_dummy BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY.
RETURN
SELECT dummy FROM "SYS".dummy WHERE dummy = :var;
ENDMETHOD.
ENDCLASS.
The reason is that the linter recognizes ";" as the end of the "Native SQL" section, but this is now hidden behind the comment. If you put the ";" on a new line, it at least parses just like the original code.
That's better. But the main problem is that it's still parsing the NativeSQL part as though it were ABAP. It tries to evaluate the code, and it will stumble:
- Dots "." are used to recognize the end of a command. In SQL it's semicolons ";"
- Double quotes are used to recognize the beginning of a line comment. In SQL these are used to escape field names, table names and schema names.
In the end, this leads to the parser to be unable to recognise the "real" end of the NativeSQL part - which is defined by a semicolon, followed by whitespace and then ENDMETHOD. For the playground, you can use the example above with the "SYS" in quotation marks. I think these are the most tricky part for the parser...
I think its getting there, https://github.com/abaplint/abaplint/pull/3491 will contain a few more fixes
Looks good, I'll run it on a larger set of code when there's the next update for the vscode extension. Thanks a lot!
I'll update the vscode extension on Friday(remind me if I forget), I'm travelling and too lazy to setup the authentication on the laptop
alternatively try running it via the command line interface, to check for bugs