Use DWARF 5 value for DW_LANG_Rust

[tromey]

DWARF 5 has assigned a value for DW_LANG_Rust. See the relevant DWARF issue. Although DWARF 5 is not yet released, it seems ok to use this value as both GCC and LLVM are already using other DW_LANG_ constants assigned in this way.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

r? @michaelwoerister

[michaelwoerister]

Let's give it a try. Debuggers will hopefully use the same fallback mechanisms they are using now if they don't recognise the value. Thanks for the PR,Tom!

[michaelwoerister]

@bors r+

[bors]

📌 Commit a0943d0 has been approved by michaelwoerister

[sanxiyn]

Eh, isn't it wise to refrain from using DW_LANG_Rust until we are somewhat sure about debug info generation scheme?

While reading through gdb source, I found many paragraphs like the following one in ada-lang.c:

The purpose of this routine is to allow us to support older versions of the compiler by detecting the use of the older encoding, and by fixing up the INDEX_DESC_TYPE to follow the new one (at this point, we essentially replace each field's meaningless type by the associated index subtype).

[tromey]

You shouldn't use the Ada support in gdb as a guide. Ada is very special in gdb, and not in a good way. For example, that quoted paragraph is actually referring to Ada's use of magic symbols to guide debuginfo interpretation, because for some historical reason the Ada compiler did not emit DWARF for all its constructs.

My past experience in debuginfo generation and reading is that compilers are never done. There are always bugs requiring workarounds in the debugger. The simplest way to dig for these in gdb is to search for "quirk". The general method here is producer sniffing, which would work just fine for Rust as well.