I get a parse error on third line of foo.h because STATIC_INLINE seems not to be resolved whereas it is defined in bar.h.
I use this macro in foo.c and macro resolution is correct (no parse error).
So, I wonder how does the build wrapper work.
Build wrapper seems to build an entry per compiled file, so per C file.
When SonarLint analyses a C file, it looks in the corresponding build output entry.
But there is no build output entry for header files, so how does it manage header files ?
Create another header file in a subdirectory (another.h in “another” dir)
Put this define in another.h: #define STATIC_INLINE static inline
Put this function main.h:
STATIC_INLINE void Toto(void)
{
}
Goto SonarLint on the fly view and you get a parse error.
The reason seems to be that SonarLint is not aware of include paths.
I found that adding “another” directory to include paths from Eclipse project solve the issue.
I was not aware that SonarLint was linked to CDT configuration and to Eclipse build.
I use Eclipse as an editor only. I don’t use it to build.
Can you tell me if I can encounter some issues with SonarLint if I don’t build in Eclipse.
I can manage include paths properly but not build within Eclipse.
Yes, clearly. Since we rely on Eclipse configuration, if you don’t build in Eclipse, this configuration can be out of sync with the configuration actually used to build, and SonarLint will not work correctly.
Even if you don’t actually use Eclipse to build your production code, maybe you can still use it to build it in some “draft” mode? In addition to enabling SonarLint, it will probably also allow Eclipse to be a better editor, with better automatic code completion, for instance.