Diagnostics for detection of endless loops

[Daniel-Cortez]

What this PR does / why we need it:

This PR implements new diagnostics for detection of endless loops:

• warning 250: variable "%s" used in loop condition not modified in loop body
  Helps to detects the cases when the user forgot to modify the loop counter variable.

new i = 0;
while (i < 10) // warning 250: variable "i" used in loop condition not modified in loop body
    DoSomething(i);

• warning 251: none of the variables used in loop condition are modified in loop body
  The same as the previous diagnostic, but works when multiple variables are used inside a loop condition and none of them gets modified.
  For the compiler there's no reasonable way to know which variable should be modified and which shouldn't, which is why I had to create a distinct warning for such situations.

for (new m = 0, n = 10; m < n; ) {} // warning 251: none of the variables used in loop condition are modified in loop body

Which issue(s) this PR fixes:

Fixes #

What kind of pull this is:

• A Bug Fix
• A New Feature
• Some repository meta (documentation, etc)
• Other

Additional Documentation:

[Y-Less]

For the compiler there's no reasonable way to know which variable should be modified and which shouldn't, which is why I had to create a distinct warning for such situations.

I don't follow why that needs two warnings. The second warning covers the first case as well, so only 251 is needed.

[Y-Less]

Could I also suggest a test for the case where one loop variable is passed by reference to a function? I know there's no way to determine if that function actually modifies it, but it would just be nice to confirm that the warning isn't given in that case.

[Daniel-Cortez]

I don't follow why that needs two warnings. The second warning covers the first case as well, so only 251 is needed.

The first one tells which variable exactly needs to be modified. Even when there's only one variable used inside the loop condition, I think it would be more convenient to have that variable pointed at right away than having to inspect the code every time to determine which variable it is. Simply removing warning 250 would mean sacrificing the said convenience.

Another option would be to merge both warnings into one, but they are two completely different messages. I mean, I could do something like this:

/*250*/ "%s modified in loop body"

so warning 250 could be both "variable "%s" used in loop condition not modified in loop body" and "none of the variables used in loop condition are modified in loop body", but currently no other warning or error does this, so I'm not sure if this would be a good solution either.

Could I also suggest a test for the case where one loop variable is passed by reference to a function? I know there's no way to determine if that function actually modifies it, but it would just be nice to confirm that the warning isn't given in that case.

Done.

[Daniel-Cortez]

Another thing worth mentioning is that warnings 250 and 251 don't work on do-while loops yet, as those need to be handled in a separate way (basically because they have the loop condition written after the loop body), but I'm already working on solving this.

[Daniel-Cortez]

The new diagnostics seem to work on do-while loops pretty well (just tested this on a few gamemodes, didn't have any false-positives) and pass all tests, so I suppose this PR should be ready now.

[Daniel-Cortez]

Amended and force-pushed some of the commits; the changes are the following:

• Changed the values of flags uLOOPVAR and uNOLOOPVAR from 0x100 and 0x800 to 0x1000 and 0x2000 respectively, in order to avoid a conflict with Fixes for function and variable declarations #631, as value 0x800 is already used for flag uDECLPUBLIC in that PR (also initially value 0x100 was supposed to be used for flag uINITIALIZED in Implement warning 210 #440, so I'm leaving it for when that PR is reimplemented).
• Fixed pc_loopcond being assigned FALSE instead of 0 in resetglobals().