Abstract Syntax Tree crashes when use SELECT FOR UPDATE

[machadowelton]

I’m make the custom rules to PLSQL analysis and am using the sslr-plsql-toolkit-3.4.1.2576.jar to guide me to find violated rules in the code blocks.

So when i parse code with a simple SELECT the Abstract Syntax Tree is mapped correcly:

CREATE OR REPLACE PACKAGE BODY package_sample_sonar_rules AS
    PROCEDURE rule21_compliant
    IS
    VAR1 INTEGER := 10;
    CURSOR cursor1 IS
        SELECT 
            col1,
            col2
        FROM
            tab1
        WHERE col1 > VAR1;
    BEGIN
        OPEN cursor1;
        CLOSE cursor1;      
    END rule21_compliant;
END package_sample_sonar_rules;
/

But i need find the SELECT WITH FOR UPDATE on code Because my rules do not allow the use of FOR UPDATE. So when add FOR UPDATE on SELECT, the Abstract Syntax Tree crashes and the SELECT on the tree is not similar to SELECT without FOR UPDATE

CREATE OR REPLACE PACKAGE BODY package_sample_sonar_rules AS
    PROCEDURE rule21_compliant
    IS
    VAR1 INTEGER := 10;
    CURSOR cursor1 IS
        SELECT 
            col1,
            col2
        FROM
            tab1
        WHERE col1 > VAR1 FOR UPDATE;
    BEGIN
        OPEN cursor1;
        CLOSE cursor1;      
    END rule21_compliant;
END package_sample_sonar_rules;
/

[felipebz]

Hi again. :-) (Yes, I'm the same person that answered you here)

Unfortunately you're using the commercial plugin from SonarSource and you'll need to ask them to fix this bug, but as you can see they know about this problem since 2012 and didn't fixed it yet. I wouldn't expect a fix soon.

However if you're willing to migrate to my plugin I could help you. I know I'm biased but I think it has a better parser than the one from the SonarSource analyzer. ;-) You can test my parser using the zpa-toolkit.

[machadowelton]

@felipebz is possible use the comercial plugin and your plugin on server?

[felipebz]

@machadowelton you can install both plugins in the same server, but you can't run both analyzers at the same time (in a single analysis). See issue #133.