I want to execute MISRA-C analysis on Embedded-C code.
The source code in git is m4 code which is preprocessed with m4. The generated source contains #line directives that are used by the compiler, debugger and all other tools to determine the original source location in the version controlled m4 code.
How can I configure SonarQube to honor the #line directive to report findings on the original m4 code?
Hey @andi, as of today, this is not supported. If I understand correctly, you run the analysis on the generated C code, right? I guess that for SonarQube to be able to trace the #line directives, it would need to access the actual m4 code in your repository at some point, most likely via project binding.
I’m going to flag this for the PMs in case they want to take this use case into account. To be fair, I don’t think this is a request we have heard before, so I would say there doesn’t seem to be a lot of demand for this feature.
I believe support for `#line` is particularly relevant for Embedded-C and MISRA-C users because code generation is common practice in this domain (AUTOSAR, model-based development, register generators, template-based approaches such as m4, etc.).
This is not limited to m4, which admittedly has been around for a long time. Code generation remains widely used in modern embedded software development, and `#line` continues to be the established mechanism for preserving source-level traceability across generated artifacts.
In these environments, developers work on the original source artifacts, while the generated C code is treated as a build artifact. `#line` provides the traceability required to map diagnostics back to the maintained source.
Without honoring `#line`, findings can only be reported against generated files. This makes integration with DevOps platforms such as GitHub less useful, since issues cannot be associated with the actual version-controlled source where fixes must be applied. It also makes remediation more cumbersome because developers need to manually trace findings back to the original artifacts.
From my perspective, support for `#line` would significantly improve the usability of MISRA-C analysis for generated-code workflows. Since many compilers, debuggers, and static analysis tools already use this information for source mapping, the lack of `#line` handling reduces the value of the otherwise very welcome MISRA-C support.