"C++ Parser can't read code. Declaration is skipped" => add info in log

[dbochard]

Hello,

We had many error "C++ Parser can't read code. Declaration is skipped"

Some of this error was generate by GCC include file not found. To workaround, we add a sonarQube.h with missing define.
Some other was due to #pragma, we replace #pragma by Macros and the Macros are empty for sonar analyze.
This solve a lot off error, but for the other parser error, it's difficult to understood the source.

One think may help to solve this trouble : is it possible, on the log in verbose mode to add the line view by the analyzer after preprocessor ? it would help to find the missing part.

Our log config :

sonar.verbose=true 
sonar.log.level=TRACE 

Best regard's

[guwirth]

Hello @dbochard,

thanks for your feedback.

First of all I like to ask you to read:

• https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Detect-and-fix-parsing-errors
• https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Dealing-with-compiler-specific-code-pieces

Furthermore, it would be interesting to get concrete examples where and how the warnings could be improved.
Do you have code examples?

Regards,

[dbochard]

Hello,

Thanks for your information. I had already look linked you proposed.

In the next sample, the parser error come from line 504. The line 504 generate multiple parser error.

After investigation of the line, it was easy to solve, but find the line witch generate all parser error was complicated. I had to comment code zone, uncomment code zone until to find the source line witch generate all parser error.

If in the log, sonar-cxx could display the source line, after pre-processor, it would be easier to understand that the function Tr_getTxtListe was not define in the scop.

Regards,

[guwirth]

Hi @dbochard,

it would be easier to understand that the function Tr_getTxtListe was not define in the scop.

The cxx plugin is only doing a syntax analysis and not a semantic analysis. That means it has a lexer reading the source code, creates a token stream and validates this against the grammar. The result is then an abstract syntax tree.

At first glance the code above seems to be syntactical correct and the root cause for the first can't read the code is not visible. What did you change to fix it? For me the declaration of Tr_getTxtListe is not necessary to validate the code?

You can try out code by your own with the SSLR toolkit (https://github.com/SonarOpenCommunity/sonar-cxx/releases). Copy and paste your code into the tool (must be plain ASCII, sometimes you have to copy to e.g. Notepad first) and press "Parse Source Code". In the sample you see also that the verification against the grammar needs no context (definition/declaration):

The main problem with syntax errors is often that the root cause is somewhere else. At the moment the message C++ Parser can't read code. Declaration is skipped is linked to the token where the parser creates a syntax error. Maybe we can add the token and the token location to the message?

Regards,

[guwirth]

@dbochard please try #2198

[dbochard]

Thank's a lot for your help.

I am sorry I have done a mistake in my previous message. I sayed Tr_getTxtListe was not define in the scop, it's wrong, the function call is replace by a macro :

#if defined(DOXYGEN)  // Pour alégéer les graph d'appel
  #define Tr_getTxtListe   (a, b) (char*)0 ///< Fonction de gestion des traduction (bouchonné pour déoxygen)
#else
  const char * Tr_getTxtListe      (typeListe *pListe, typeIndex indexItem);
#endif

and for sonar DOXYGEN was defined.

so the line

      strncpyUfx(textTmp, (char*) Tr_getTxtListe(&pListeDouble->index2.infoListe.liste, iChoix), sizeof(textTmp));

should be analyzed like

      strncpyUfx(textTmp, (char*) (char*)0, sizeof(textTmp));

I don't understand why it create a parser error, but I modify the project analyse to not use DOXYGEN define for sonar analyses

Some years ago I had the same trouble with line like :

sprintf(&string, "Data : %" PRId64 "/r/n", data);

gcc include are not found, so PRId64 is not known and the analysed line is :

sprintf(&string, "Data : %" 0 "/r/n", data);

and generate many Parser error. Concatenate string with 0 create the parser error. I solved by adding PRId64 in a sonarQube.h.

To find source line, I comment code, launch sonar, un-comment code, launch sonar,... until to find the line.

So, if sonar had displayed the analyzed line it had help to find the line source of the parser error.

Regards

[dbochard]

I try to install your #2198 plugin version.

My sonar server still is in 6.7.3, it seems your new plugin version is not compatible, my server do not restart with the new version. I go back to the version 1.2.2.1653

We schedule to ubgrade our server to 8.9 LTS, I will retry when done.

Thanks a lot for your reactivity.

Regards

[guwirth]

Hi @dbochard,

I'm sorry we can't fix issues in 1.2, it's too old.

Trying this with 2.0 it's working with/without defining DOXYGEN

#define DOXYGEN
#if defined(DOXYGEN)
   #define Tr_getTxtListe(a, b) (char*)0
#else
   const char * Tr_getTxtListe(typeListe *pListe, typeIndex indexItem);
#endif

void f1() {
  strncpyUfx(textTmp, (char*) Tr_getTxtListe(&pListeDouble->index2.infoListe.liste, iChoix), sizeof(textTmp));
}

This issue is still a known issue and we are searching for a solution (#1697):

sprintf(&string, "Data : %" PRId64 "/r/n", data);
sprintf(&string, "Data : %" 0 "/r/n", data);

Some other was due to #pragma

Here I'm interested in concrete samples. Could you provide one please?

Regards,

[dbochard]

Hello,

Please look at a code witch generate parser error :

  struct {
    int64_t ok[ESC_NP_PTS];
    int64_t delta[ESC_NP_PTS];
  } tempsCalcu __attribute__((section(".RamExtSection")));

The error come from __attribute__((section(".RamExtSection")))

I solve them by adding #define __attribute__(a) in my sonarQube.h

An other trouble come from line like :
__ASM volatile("BKPT");
In this case, I'm not sure a can solve with a macro.

Regards,

[guwirth]

Hello @dbochard ,

thanks for the sample.

The decision in this plugin was to support only standard conform C++ and try to solve such issues with the preprocessor. Mostly it is the easiest to create an header file and include it with https://github.com/SonarOpenCommunity/sonar-cxx/wiki/sonar.cxx.forceIncludes.

Sample: https://github.com/SonarOpenCommunity/sonar-cxx/blob/master/cxx-sensors/src/main/resources/macros/GxxMacros.h

This should work for the points above:

#define __attribute__(...)
#define __ASM asm

Maybe we can document this better?

Regards,

[dbochard]

I juste upgrade our sonar to 8.9 and CXX 2.0.4.

and I tried to use my SonarQube.h in sonar.cxx.forceIncludes, it's very usefull, I d'ont need any more to add #include for sonar in the project.

Your proposal is also usefull :

#define __attribute__(...)
#define __ASM asm

It has remove some Parser error.

About #2198, the modification add ', line=xxx, column=xx on the report, I seems to be very useful to understand the source.

Example:

In this file, we have many parser error, with your modification, It is clear that all parser error are on curly brace and I found the source : there is no :

#ifdef __cplusplus
 extern "C" {
#endif

at the beginning of the file.

In fact, to solve this we will remove the #ifdef __cplusplus from our C file, it is not necessary.

Thanks for your help and your reactivity

David

[guwirth]

Hello @dbochard,

because this plugin is a C++ plugin, we added __cplusplus to the predefined macros. It should be possible to add a #undef __cplusplus to remove it.

Regards,