suggestion: exclude non-abap language parts from linter

[jkadw]

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

[jkadw]

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.

[larshp]

they do identify as NativeSQL, so need to exclude those "statements" from the rules

[larshp]

@jkadw try again, 2.113.68 published

[jkadw]

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.

[larshp]

thanks, reproduces in the playground,

[jkadw]

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"...

[jkadw]

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.

[jkadw]

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.

[larshp]

@jkadw try again, 2.113.69 published

[jkadw]

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:

1. Dots "." are used to recognize the end of a command. In SQL it's semicolons ";"
2. 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...

[larshp]

I think its getting there, #3491 will contain a few more fixes

[larshp]

the syntax highlighting is not correct, but the linter is happy,

[jkadw]

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!

[larshp]

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

[larshp]

new vscode extension published, it will show up in a bit

[larshp]

@jkadw any luck?