Lexer error #1648
Comments
|
Found from where the error message is emitted: com.sonar.sslr's lexer |
|
Hi @X-Ryl669, thx for your feedback. Please try to
Check also the encoding of your source files. Are they utf8? Regards |
|
Removing blanks does not make any difference, nor does removing backslashes. Also, removing the include directive allows the lexer to progress, but I'm getting syntax errors (obviously), thus no interesting report. |
|
After bisecting the include directories, I'm sure the parser & lexer is working (the source code appears in the web interface) but I'm still getting syntax errors ( Is there a way to display the AST of each input file as it's being understood? |
|
@X-Ryl669 to get more information turn debug info on: If you wanna see the AST you can use the SSLR toolkit. Download and start it and copy the source code into it. You can also set includeDirectories there. |
|
Debug is already on, yet it does not dump AST nor the reason for syntax error. |
|
|
Thanks! This is accepted: Please notice that I'm compiling C++14 code, so it should be OK to use ">>>" to end a template declaration. Also Yet, I'm able to parse 100% of the code (I've tried each file by hand) and it all parses correctly in SSLR toolkit, but |
|
Activated the rules tagged "tool-error" So to sum up the issues and workaround:
|
|
@X-Ryl669 thx for narrow this down.
|
|
|
I'm using xtensa's ESP32 compiler which is a port of gcc 5.2.0. containerof/offsetof are defined here @ivangalkin I've already captured all include dir (not that hard to do, via a make -n + regexp). The issue is that if I use that list of directories, it fails. I have to bisect the list to find out the part that would allow the parser to work. IMHO, the sonar-scanner should report the complete SSLR's exception stack trace & message when such exception is generated, so at least, when bisecting we get a message telling where to look at instead of being blind. I'm sure it's possible to do it, since the SSLR toolkit is doing it already. |
I agree, that tracing of |
|
@X-Ryl669 I did some test with the SSLR toolkit 1.2.1: Failing => new issue: extern const char cert_start[] asm("_binary_firmware_pho_by_crt_start");Works, can't reproduce it: UARTTask<BL6523GXController<UART<UART_NUM_2, 4800, 8, 'N', 1>>> uartTask;Works, can't reproduce it: struct A { unsigned b:17; unsigned c:15; };Works, can't reproduce it: struct S {
char c;
double d;
};
int main()
{
std::cout << "the first element is at offset " << offsetof(S, c) << '\n'
<< "the double is at offset " << offsetof(S, d) << '\n';
}C++/CLI not C++: typeof / containerof |
|
Do you need my parsing errors ? I think you need the (simplified) declaration of the failing code, so here it is: and and I'll give the exact parsing error when I'm back at home. |
|
Here is the exception from the CxxToolkit for container_of: Here is the exception for the |
|
@X-Ryl669 samples above are working with SSLR-1.2.1, except: #define esp_container_of( ptr, type, member ) ( { \
const typeof( ( (type * )0 )->member ) *__mptr = ( ptr ); \
( type * )( ( char * )__mptr - offsetof( type,member ) );} )
static CgiStatus logRequest(HttpdConnData *connData)
{
char * ip = esp_container_of(connData, RtosConnType, connData)->ip;
}Problem is this |
|
What's VS ? |
|
Concerning the bitfield issue: The parser seems to accept them, but they are not understood as bitfield. In fact, this leads to strange errors with the rules about bad type (I'll copy them when I'm back home again). This looks like a parser output error (it does not produce a good AST), even if it continues parsing the rest of the code correctly. The |
|
@X-Ryl669 VS = VisualStudio Seems to be no C++? char * ip = esp_container_of(connData, RtosConnType, connData)->ip;
char * ip = ({ type a = something; (rettype*)(a - 35); })->ip; |
|
I don't know for sure. When you have multiple statement per line (like I don't know if the In the end, the expression resumes to This is accepted by all C++ compilers, so I would say it's correct (see this ideone ). I agree that's not usual code, but if it's compliant, it should be parsed. |
|
Concerning the So the error is not the number of This is strange since there is no macro involved in this statement ( Is there a way to capture the preprocessed string of the SSLR toolkit ? |
|
@X-Ryl669 which compiler are you using? |
|
It's a Xtensa ESP32 cross compiler based on GCC5.2. |
|
see #1685 |
I've the same issue as #872 but it was closed without resolving.
I'm getting a
Lexer error: Unable to lex urlfor each source file.Here's the output of the sonar-scanner's log:
I've added the macros for the compiler extensions, and here's my
project.properties:The text was updated successfully, but these errors were encountered: