[gdb/cli] Use debug info language to pick pygments lexer

Consider the following scenario:
...
$ cat hello

int
main (void)
{
  printf ("hello\n");
  return 0;
}
$ gcc -x c hello -g
$ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x4005db: file hello, line 6.
Starting program: /data/vries/gdb/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at hello:6
6	  printf ("hello\n");
...

This doesn't produce highlighting for line 6, because:
- pygments is used for highlighting instead of source-highlight, and
- pygments guesses the language for highlighting only based on the filename,
  which in this case doesn't give a clue.

Fix this by:
- adding a language parameter to the extension_language_ops.colorize interface,
- passing the language as found in the debug info, and
- using it in gdb.styling.colorize to pick the pygments lexer.

The new test-case gdb.python/py-source-styling-2.exp excercises a slightly
different scenario: it compiles a c++ file with a .c extension, and checks
that c++ highlighting is done instead of c highlighting.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966

0 files changed, 0 insertions, 0 deletions