Enter forum description here ...
No similar topics found.
+1
Planned
Enhancement suggestion for "Empty <anything>" rules (W501, W502, W505, W506)
In some cases it is desired to have an empty else, except, ... block.
The suggestion is to relax the rule under certain conditions. One condition would be that the empty block contains a comment, which hopefully explains why the block is empty.
Visually this could look like the following:
with the above setting for the following code example:
Fixinsight would not warn about the empty exception, but warn about the empty finally block
The suggestion is to relax the rule under certain conditions. One condition would be that the empty block contains a comment, which hopefully explains why the block is empty.
Visually this could look like the following:
(X) W501 Empty EXCEPT block
(X) Accept comments
(X) W502 Empty FINALLY block
( ) Accept comments
with the above setting for the following code example:
procedure yeah(something, crazy:integer);
begin
try
try
something := crazy div 0;
except
// we can safely swallow the exceptions here
end;
finally
// nothing to clean up
end;
end;
Fixinsight would not warn about the empty exception, but warn about the empty finally block
+1
Under review
allow the Suppress Warnigs comment to be in a separate line
Currently the // FI:Wxxxx comment to suppress a warning must be in the line that contains that warning. In some cases, e.g. "W506: Emtpy ELSE block" it would be more convenient to put it into its own line. e.g.:
case _Idx of
case _Idx of
0: Result := GetValid(Laser0OutUpMask);
1: Result := GetValid(Laser1OutUpMask);
2: Result := GetValid(Laser2OutUpMask);
else // FI:W506
// ignore
end;
should also allow:
else
// FI:W506 ignore
end;
Currently we already have an // ignore comment there so adding the FI:W506 would not be such and eye sore.
+1
Planned
Add warning when function result always undefined and differentiate this from [w521]
Add special warning when function newer assign any value to its result.
Why its needed to differentiate? Because such function can be easily converted into procedures. It can be not a forgotten result in some special case, but procedure, declared as a function.
+1
Completed
Support for includes (e.g. {$I Directives.inc})
At the moment it seems that they are ignored.
+1
Planned
[W510] False positive with string concatenation
String concatenation leads to false positive W510
StringParamProc('A' + 'A'); //[FixInsight Warning] <unit>(<line>): W510 Values on both sides of the operator are equal
In the real life code the param is a delimiter, which is "sLineBreak + sLineBreak"
StringParamProc('A' + 'A'); //[FixInsight Warning] <unit>(<line>): W510 Values on both sides of the operator are equal
In the real life code the param is a delimiter, which is "sLineBreak + sLineBreak"
+1
Planned
Project source code is not taken into account
Steps:
- create a new console app
- add some code to the project source code that is supposed to generate a warning
- run FixInsight
Expected: the supposed warning is generated
Actual: no warning is generated
- create a new console app
- add some code to the project source code that is supposed to generate a warning
- run FixInsight
Expected: the supposed warning is generated
Actual: no warning is generated
+1
[W521] False positive when Result is set in a function call
Example:
function MyObj.Convert(Value: String): THexWert;
begin
if Assigned(fConversion) then
fConversion.Convert(Wert, Result)
else
Result := 0;
end;I think it's safe to assume that fConversion.Convert now has the responsibility to set Result, if it is a var parameter of fConversion.Convert.
possibly related to http://fixinsight.userecho.com/topic/677142-w521-false-positive-with-result/
+1
Started
FixInsight 2015.4 xml log files are cut off
The xml files created by FixInsight 2015.4 are cut off at some random location. I have not found out why. The number of messages doesn't seem to be an issue, because it happens with files that are 50 lines long or > 500 lines long.
Example:
Example:
<file name="xxxxx.pas">
<message line="85" col="3" id="W508">W508 Variable is assigned twice successively</message>
<message line="102" col="3" id="W508">W508 Variable is assigned twice successively</message>
<message line="140" col="17" id="W512">W512 Odd ELSE-IF condition (review lines 140 and 144)</message>
<message line="574" col="7" id="W521">W521 Return value of function 'ParseFixVarUnion' might be undefined</message>
<message line="799" col="3" id="W521">W521 Return value of function 'ParseBLOCK' might be undefined<It is just cut off in the middle of an xml tag.Customer support service by UserEcho
