You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The strengthening of the analyzer against unexpected exceptions (see SONARJS-970) has introduced a side-effect : the SeCheck, base class for all our Data Flow Analysis checks, contains an instance field that stores all issues raised during analysis and returns them to the Sensor on SeCheck.scanFile. In case of an exception raised by a SeCheck that specific check's issues list never gets cleaned up, since the exception management happens much above and the next SeCheck.scanFile happens only when the next file is being analyzed.
If we are lucky and the next file is shorter than the previous one, a new exception is likely raised when issues collected in the previous file are saved with an higher line number that is larger than the current file lines (save issue at line 400 when file has only 300 lines). If instead we are not lucky, the issue from the previous file gets saved on the new file, showing issues that make no sense to the user and which are almost impossible to point back to this case (something like : why is SonarQube showing a "useless increment" issue on the second and third letter of a function name??).
The text was updated successfully, but these errors were encountered:
SonarJS version: Since 3.0-RC1
Rule key: Any SeCheck rule
The strengthening of the analyzer against unexpected exceptions (see SONARJS-970) has introduced a side-effect : the
SeCheck
, base class for all our Data Flow Analysis checks, contains an instance field that stores all issues raised during analysis and returns them to the Sensor onSeCheck.scanFile
. In case of an exception raised by aSeCheck
that specific check's issues list never gets cleaned up, since the exception management happens much above and the nextSeCheck.scanFile
happens only when the next file is being analyzed.If we are lucky and the next file is shorter than the previous one, a new exception is likely raised when issues collected in the previous file are saved with an higher line number that is larger than the current file lines (save issue at line 400 when file has only 300 lines). If instead we are not lucky, the issue from the previous file gets saved on the new file, showing issues that make no sense to the user and which are almost impossible to point back to this case (something like : why is SonarQube showing a "useless increment" issue on the second and third letter of a function name??).
The text was updated successfully, but these errors were encountered: