Issues that don't report a filename are not handled correctly

[AbbasNS]

Description

Some of the C and C++ rules can be triggered without a specific filename. For example, S3744 will be triggered if when a macro is defined multiples times with different values as a compiler option. This rule will not have an associated filename since the issue doesn't exist in a specific location of the file.

When it happens, the subprocess.exe finishes successfully, however it returns an issue without filename, which causes SLVS to crash.

Repro steps

Create a C++ project and define a macro to two different values using additional options:

When analyzing the file you will get a crash while reading the analysis results:

Expected behavior

Handle rules without an associated file. Maybe display them a warning without mapping them to a specific location

Actual behavior

No issues are reported for the file (it's also possible no issues will be reported for the entire project, depending on which rule was triggered. See explanation from @abbas-sabra-sonarsource below.).
A message is logged in the SonarLint output window.

Known workarounds

Disable the rule causing the issue from the setting file:

[rita-gorokhod]

Another reproduction scenario: Define a macro using additional options to a non-portable file path, which will trigger S3806, such as /FI C:\projects\foo.h

Expected: No crash.
Actual: Same crash as above, "non-portable path to file '"C\Projects\foo.h"'; specified path differs in case from file name on disk".

[duncanp-sonar]

@abbas-sabra-sonarsource thanks for creating the issues.
I've updated the Actual behaviour section to try to describe the impact the user experience. Could you check that it's accurate please?
Also, is it a regression or is it an issue that has been around for some time?

[AbbasNS]

@duncanp-sonar, It isn't that analysis fails, the analysis succeeds and returns meaningful issues. the problem happens when we have issues(in this case "code smell") with no specific location(filename). For example, we can find code smell on macro/code defined through additional options => they will not have a real location in the file. We should simply check if the filename is empty before calling GetFullPath.

Q: does it depend on whether the current file being analysed uses the invalid macro?
No.
It isn't an invalid macro. It is valid, It is just a code smell to override the value of a macro in the options. SLVS should either skip these type of issues with no filenames and display the rest, or find a way to display them without a specific location.

Q: does this mean that no issues are reported for any file in the project?
It depends if the entire project is using the same options. or if the option is specified for one file. usually, compilation options are specified per project, not per file.

by the way, there are other kinds of issues that usually don't have a filename. For example when one of our rule input is badly configured we raise an issue with no filename.

Q: Also, is it a regression or is it an issue that has been around for some time?
I don't think this was recently introduced.

Let me know if further clarification is needed.