[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

1 files changed, 2 insertions, 1 deletions

diff --git a/gdb/source-cache.c b/gdb/source-cache.c
index 30c9e61..2c3ad34 100644
--- a/gdb/source-cache.c
+++ b/gdb/source-cache.c
@@ -364,7 +364,8 @@ source_cache::ensure (struct symtab *s)
       if (!styled_p)
 	{
 	  std::optional<std::string> ext_contents;
-	  ext_contents = ext_lang_colorize (fullname, contents);
+	  ext_contents = ext_lang_colorize (fullname, contents,
+					    s->language ());
 	  if (ext_contents.has_value ())
 	    {
 	      contents = std::move (*ext_contents);