syntax highlighter has issues with raw string literals

[milleniumbug]

Code fragment used:

int main()
{
    R"(  "test\n"   )" == "test\n";
    R"( "te\tst\nkol\\\\es" )" == "te\tst\nkol\\\\es";
    R"( "\112\113\114" )" == "\112\113\114";
    R"***( "\"\x53\x5A" )***" == "\"\x53\x5A";
    R"***( "\"\\\t\\\\\t\f\b\xFF" )***" == "\"\\\t\\\\\t\f\b\xFF";
}

Fedora 23, clang version: 3.7.0

[eidheim]

We have two syntax highlighting engines, one fast one through gtksourceview, and one slow one through libclang. The problem here seems to be gtksourceview's cpp.lang setting the last two == to red (same color as constants).

[eidheim]

Think I'm adding won't fix on this one, as this is something that has to be fixed on the gtksourceview project.

[milleniumbug]

This begs the question why doesn't libclang's highlighter fix up the mistakes once it hits. (no idea how these work, but I think it could fix it up. Or can't it...?)

[zalox]

@eidheim This is not an gtksourceview issue, it's either our fault or llvm. Reproduce by creating a new C++ project in juci++ and replace the main with the one @milleniumbug provided.

[zalox]

I think it might be solvable with the right priority on tags.

[eidheim]

At the moment, to save processing power, only some types are used from the libclang library. But feel free to play around with source.clang_types in preferences. However, the issue remains in gtksourceview and should be fixed there.

@zalox I tested by turning off the gtksourceview highlighting. When using only libclang it was correct since the == was already white.

[zalox]

These cases are rare I suspect, but we are advertising excellent syntax highlighting and auto-completion. Might there be a marked for a "power-saving"-setting?

[eidheim]

Let's not overcomplicate things. Such small issues will always exist, and creating workarounds for all of them would make the project less clean in my opinion. This issue for instance will most likely affect all kinds of tokens, not only ==, but fixing it on gtksourceview's cpp.lang will fix it for all these cases. These language files require contributions too now and in the future. Typescript language definitions are missing for instance I think still. Someone should add it (just base it on the javascript lang-file).

[zalox]

I agree, the best option is to update the cpp.lang. I guess the option for removing the gtksourceview highlighting already exists anyway. (by moving cpp.lang.)

[milleniumbug]

I've checked the cpp.lang file, and it's support for C++-specific features is just too poor. I also checked the c.lang file and I think such support for raw string literals would be possible to implement in their framework. (yay, yet another side-project :) )

[eidheim]

Hehe, I have the upmost respect for the gtk projects and the people working on these, although spending quite a few hours in the last weeks with issues with their gtk and related project 3.20 releases.

[milleniumbug]

FTR I reported the bug here https://bugzilla.gnome.org/show_bug.cgi?id=766078