Variable casing error incorrectly reported if it happens to match a keyword

[BrianGarland]

A Variable name casing error is reported if you use the POS() keyword on a DS subfield and happen to have a variable named Pos (short for position).

[worksofliam]

@BrianGarland Please paste a snippet I can copy to recreate :)

[BrianGarland]

@worksofliam Here you go:

DCL-DS MagicDS QUALIFIED;
    Char      CHAR(5000) POS(1);
END-DS;

DCL-S Pos         INT(5);

I've tried a dozen times to get it to format it as code. It is not working for me today.

[worksofliam]

@BrianGarland I have tried to recreate this and I cannot as of 0.20.1. Please try again, and if you're still getting it, share a fuller example and also your rpglint.json file. Thanks

[BrianGarland]

With the latest of all extensions installed, I can still reproduce it.

`**FREE DCL-DS MagicDS QUALIFIED; Char CHAR(5000) POS(1); END-DS;

DCL-S Pos INT(5);

MagicDS.Char = 'x';

RETURN; `

{ "indent": 4, "NoGlobalsInProcedures": false, "PrettyComments": false, "NoOCCURS": false, "UppercaseConstants": true, "UselessOperationCheck": true, "CopybookDirective": "include", "StringLiteralDupe": false, "IncorrectVariableCase": true, "RequireBlankSpecial": false, "NoUnreferenced": true, "UppercaseConstants":true, "SpecificCasing": [{"operation":"*DECLARE","expected":"*upper"}, {"operation":"*BIF","expected": "*upper"}] }

[SJLennon]

@worksofliam If you are looking at this, I have a similar minor issue with the "main" keyword on the ctl-opt statement. It gets confused if my proc is named Main.. (It's not hard to work around, so it's minor.) If I change it to something other than main it doesn't complain.

Here's a small bit of code that makes it happen:

**free
ctl-opt debug  option(*nodebugio: *srcstmt) dftactgrp(*no) actgrp(*caller)
main(Main);
dcl-proc Main;
    dsply %CHAR(CalcDiscount(10000));
    dsply %char(CalcDiscount(1000));
    x = %TIMESTAMP(y);
    y = %TimeStamp(x);
    return;
end-proc;

[worksofliam]

@BrianGarland @SJLennon

So it looks like my original claim that I fixed this was false. I actually wrote an invalid test which I didn't see until today.

Now, however, your issue has been fixed. The fix will be released when Code for IBM i 2.1.0 has been release - hopefully later this week.

[worksofliam]

0.21.0 is being deployed and the fix for this is included. Thanks!