SonarQube for IDE 12.2.2 in CLion reports existing C/C++ files as “File to analyze was not found” an

Environment
• OS: Linux
• IDE: CLion 2026.1.1
• SonarQube for IDE plugin: 12.2.2.84629
• Language: C/C++
• Connected mode: Yes
• SonarQube Server: on prem
• Project type: CMake, out-of-source build
• Compiler: Texas Instruments armcl
• CFamily analysis configured with compile_commands.json

Description
SonarQube for IDE fails to analyze C/C++ files in CLion. The files exist on disk and are part of the CMake build/compilation database, but the plugin reports them as missing:
File to analyze was not found in the file system
After that, the analysis starts with an empty inputFiles list and immediately exits with No file to analyze.
This happens consistently for multiple files.

Observed Logs
[2026-05-18T16:21:43.534] [SonarLint Server RPC request executor] ERROR sonarlint - File to analyze was not found in the file system: file:///home/ragnar.margus%40milrem.lan/git/embedded_control_units/ttc/examples/ADC/src/main.cpp
[2026-05-18T16:21:44.523] [SonarLint Server RPC request executor] ERROR sonarlint - File to analyze was not found in the file system: file:///home/ragnar.margus%40milrem.lan/git/embedded_control_units/auto_generated/can_dbc/sources/milrem/debug_can/device_can.hpp
[2026-05-18T16:22:07.245] [sonarlint-analysis-scheduler] ERROR sonarlint - File to analyze was not found in the file system: file:///home/ragnar.margus%40milrem.lan/git/embedded_control_units/ttc/electrical/app/main.cpp
Analysis then starts with no input files:
baseDir: /home/ragnar.margus@milrem.lan/git/embedded_control_units
extraProperties: {
sonar.cfamily.build-wrapper-content={“version”:0,“captures”:}
}
activeRules: [494 cpp, 208 c, 2 text, 353 secrets, 16 ansible, 24 githubactions, 132 plsql]
inputFiles: [
]

No file to analyze
Analysis detected 0 issues and 0 Security Hotspots in 0ms

Important details
The original project path contains @:
/home/ragnar.margus@milrem.lan/git/embedded_control_units
The log uses URI-encoded %40:
/home/ragnar.margus%40milrem.lan/…
This initially suggested URI/path decoding issues. To rule that out, I created and opened a clean copy under:
/tmp/embedded_control_units-sonarlint

Then configured:
sonar.cfamily.compile-commands=/tmp/embedded_control_units-sonarlint/build/compile_commands.json
The same problem persisted:
baseDir: /tmp/embedded_control_units-sonarlint
extraProperties: {
sonar.cfamily.compile-commands=/tmp/embedded_control_units-sonarlint/build/compile_commands.json,
sonar.cfamily.build-wrapper-content={“version”:0,“captures”:}
}
inputFiles: [
]

No file to analyze
And for an existing file:
File to analyze was not found in the file system:
file:///tmp/embedded_control_units-sonarlint/ttc/electrical/app/main.cpp

Verification
The file exists:
ls -l /tmp/embedded_control_units-sonarlint/ttc/electrical/app/main.cpp
The file is also present in the compilation database:
rg ‘ttc/electrical/app/main.cpp’ /tmp/embedded_control_units-sonarlint/build/compile_commands.json
The project builds successfully in CLion:
Build | electrical | config-TTC500-Debug
/tmp/embedded_control_units-sonarlint/build
[258/258] Linking CXX executable /tmp/embedded_control_units-sonarlint/artifacts/Debug/electrical/electrical.out
Build finished

Expected behavior
SonarQube for IDE should resolve the file URI, include the opened file in inputFiles, and analyze it using the configured compile_commands.json.

Actual behavior
SonarQube for IDE reports the existing file as not found, filters it out, sends an empty inputFiles list, and performs no analysis.

Related issues
This looks similar to previously reported SonarQube for IDE file/root resolution issues where valid files are filtered out before analysis:

Question
Is this a known CLion/Linux/C++ issue in SonarQube for IDE? Is there any additional logging I can enable to diagnose why the backend considers an existing file URI missing?

Hi,

Welcome to the community and thanks for this report!

Could you provide a verbose log from IDE startup through to the error?

 
Thx,
Ann

Hello Ann,

Here is a log with verbose enabled.

sq_for_ide_verbose.log (129.1 KB)

I kept the file the same as the previous one, I know that it’s auto generated, it is still included in the CmakeLists.txt and final binary.

Hope that the log gives you more details.

Best,

Ragnar

Hi Ragnar,

Thanks for the log! I’ve flagged this for the experts.

 
Ann

Hey @ragnarmargus, many thanks for the detailed report!

This is not primarily a path or decoding issue. SonarQube for IDE excludes C/C++ files when CLion cannot provide a supported compiler configuration. With TI armcl (reported as Unknown), files are excluded before analysis. Opening the file still triggers analysis, but because excluded files are not synced to the backend file index, the core logs “File to analyze was not found in the file system” even though ls succeeds.

Setting sonar.cfamily.compile-commands does not bypass this CLion-side gate today.

As a workaround, you could analyze with a GCC/Clang CMake profile in the IDE, or use CI scanner + compile_commands for the embedded build.

Hello, thanks for the answer.

We have a separate CMake profile for unit testing, using this and only analysing the files that are included in it (excluding the embedded HAL), I was able to get an analysis going. The analysis reports 0 issues, although we have at least 2 standing medium-level issues reported in the SonarQube Server configuration.

The analysis runs through really fast as well.

Clion_differentCmakeConfiguration.txt (53.8 KB)

Thanks for the quick reply, analysis now reaches our CPP analyzer! However, it reports 0 compilation units analyzed. Build-wrapper paths use the real filesystem path (...@milrem.lan...) while input file URIs use %40 encoding. Our analyzer cannot match them, so no C++ rules run.

This time, it effectively looks like a SonarQube for IDE bug with @ in Linux paths. I suppose that if you try again in a folder without any special character, it would work.

We’re investigating this specific path problem.

Hey, sorry for the lack of reply. We likely identified the issue and we will try to include a fix in an upcoming release. Here’s the ticket for reference.

Thank you for your help!