(cpp) function declaration claims variable declarations incorrectly

[unaiur]

In highlight.js 9.2, the following code isn't recognized as C++:

int main()
{
    CUrlQuery q(request.GetQuery() ? request.GetQuery() : "");
}

I detected the following throw while detecting the language:
Illegal lexeme "?" for mode "function"

[unaiur]

I've managed to reduce the example to its minimal expression:

This is detected as perl and it throws Illegal lexeme "?" for mode "function" while detecting C++
hljs.highlightAuto("int q(f ? f : 0);");

This is correctly detected as C++
hljs.highlightAuto("int q = f ? f : 0;");

Two options are perfectly valid expressions in C++, and the first one is the only way to call object constructors in C++ 2003

[Sannis]

Highlight.js relevance system works bad for such short pieces of code. On first piece:

[perl: 7, vbscript: 4, cpp: 3]

[isagalaev]

@Sannis the actual problem is not mis-detection. We have a rather simplistic rule for highlighting function definitions, so anything that starts with a b( is considered one. In this example it's not a function definition at all, it's a variable initialization. This is very closely related to #1104.

I'm not sure how to fix it yet. One simple answer would be to simply drop highlighting function definitions altogether but that would remove a lot of relevance from C/C++ and degrade highlighting.

[isagalaev]

Status update: I believe an oncoming backtracking parser (#1140) will allow us to constrain a function definition to only have something that looks like arguments within the parentheses, so it won't touch constructs like type ident(a + b);

[joshgoebel]

Related to #1222

[joshgoebel]

If anyone gets around to this we should add tests for some of the great examples that can be found here:

https://stackoverflow.com/a/4324780/12430243

Regarding lambdas, function within function, static type functions inside functions, etc.

[joshgoebel]

This is much improved since 2016 though... the code isn't flagged as illegal anymore... but it's still mistakenly assumed to be a function definition.

[joshgoebel]

Closing because:

• Original issue is actually resolved: "the following code isn't recognized as C++"
• Secondary issue "function declaration claims variable declarations incorrectly" is impossible to resolve with current parser AFAIK, so this issue is effectively "dead".
• If there is some smart way to do this with the current parser no one has found it in 4 years, so I'm guessing no.

Rather than leave issues like this potentially open forever I am closing. One day if we switch to a backtracking parser we can naturally re-review edge cases like this (among other things).