Rust syntax highlighting

[KillTheMule]

One can debug rust programs with gdb, and by extension kdbg. It would be nice so have a bit of syntax highlighting for it, though. I'd not put in too much, just a color for the keywords (maybe a different one for the control flow keywords), one for strings, and if you want to get fancy, one for macros. Thanks for thinking about it, and thanks for kdbg :+1:

[j6t]

If GDB treats Rust code differently than C/C++ code, for example, by using a different expression syntax, things start to become tricky. Variable displays may not work anymore.

[fedenator]

Quickly looking at the code at how HighlightCpp is implemented I don't see how it would make a difference how gdb treats rust code. Am I missing something?

[j6t]

Class HighlightCpp is only for syntax highlighting in the source code window. It has nothing to do with how GDB treats Rust code.

To handle Rust code, two things are needed:

1. A parser that handles the output of GDB, if (and that's a big if) GDB treats Rust very different from C. Look at the various parse* functions in gdbdriver.cpp
2. A method to construct Rust expressions to feed to GDB for the Variables window, if GDB expects expressions in a different syntax. See VarTree::computeExpr() in exprwnd.cpp.

[KillTheMule]

For the record, I was only talking about syntax highlighting in the source window.

That said, I wanted to point out the wrapper script for gdb that's distributed with rust, maybe it sheds some light on something (I don't really understand how rust works in gdb, honestly).

[Petross404]

Speaking of syntax highlighting, what about using KTextEditor? It can use the KF5 syntax highlighting framework out of the box

[j6t]

I would not have an objection to replace the current code display by KTextEditor. Note though that all current features must still be available: non-consecutive line numbers due to disassembly, icons in front of the lines, disassembly intermingled with highlighted source code, read-only mode, but still arbitrary selection. Full-line highlight for the current line would be nice to have.

[Petross404]

I would not have an objection to replace the current code display by KTextEditor.

That sounds interesting.

Note though that all current features must still be available..

Sure, otherwise it wouldn't be an improvement. I am currently writing a toy project with KTextEditor and I am still trying to figure out how to make things work, or what's best in the using "KPart vs KTextEditor as a library" dilemma.

But I will keep this change in mind.