Warning for local var in code sent as argument

[rebelvg]

private _string = "text";

[{
    systemChat _string;
}, [_string], 0] call CBA_fnc_waitAndExecute;

This will not show a warning for systemChat _string.
In this case, {} is not only a new scope, it's an argument. So in this case it will produce an error in-game because _string wasn't defined in that scope.

[rebelvg]

Addition.
Same happens with spawn command.

private _string = "text";

[] spawn {
    systemChat _string;
};

will not show an error but will in-game.

[LordGolias]

I agree that this is an issue. For the spawn, we can easily fix it because it is pretty clear what is wrong.

For the other one, I am not sure how to handle it. Should we assume that it is run as spawn? as call? This example is somehow related to the issue #16 you raised: what assumptions should we make about code that is assigned to a variable in the script.

[rebelvg]

Yeah, I see what you mean.
I agree, it's a tough one.

[kymckay]

You could introduce a new exception level for cases like these where something could be an issue, but you can't be sure (SQFUncertainty or something)? Ideally (if you did go this route) with a command line argument to enable it in the linter if desired

[LordGolias]

While working on my version of antistasi, found a way to address this (not the spawn part, which is still wrong from the parser).

Code that uses a certain variable from an outer scope can be specified via the comment //USES_VARIABLES ["_x"] to indicate that, in that scope, the variable is correctly being used.

I have been using it to remove the errors for things like

private _selectCondition = {
     _x == 2
};

x = x select _selectCondition;

by adding

private _selectCondition = {
    //USES_VARIABLES ["_x"]
    _x == 2
};

This adware with a well-established policy in some programming languages (most notably Python) of making everything explicit: this comment explicitly informs the developer that the function uses something from an outer scope.

Another example of this kind is the _inputX used by the sorting function passed to BIS_fnc_sortBy.

[LordGolias]

I have marked this as fixed because with 68b6e95 when the code used in spawn uses a local variable, it is marked as undefined. The other case is not a well defined issue that the analyzer can catch because it depends on the source code of the function being called (is it using _input1?), and would require the other analyzer to parse the other function's code to catch.