Consider using DWARF modules instead of namespaces.

[eddyb]

Looking at the DWARF5 spec I noticed it supports "modules", with Modula-2 and Fortran given as examples, not just "namespaces" (typically associated with C++).

However, it's unclear if we can do everything we use namespaces for, with modules, and whether debuggers support modules at all.

Also see #33123, which seems potentially related.

cc @michaelwoerister

[bjorn3]

I believe lldb for latest debian only supports DWARF4.

Edit: DW_AT_module also exists for DWARF4.

[bjorn3]

DW_TAG_visibility can be attached to DW_TAG_module but not DW_TAG_namespace.

[michaelwoerister]

I think I tried using DW_TAG_module when initially implementing this but GDB didn't handle them back then. In general I'm against changing our debuginfo encoding without a proper plan (or if it's a bug fix). In the future when Rust is properly supported in DWARF then DW_TAG_module would be my preferred option too though.

[tromey]

gdb handles DW_TAG_module a little, but apparently mostly in a Fortran-specific way. If this is a change you plan to make, its easy enough to change gdb, though.

DW_TAG_visibility can be attached to DW_TAG_module but not DW_TAG_namespace.

This kind of thing isn't immensely important because it is commonplace to extend DWARF in these ways -- add "unexpected" attributes or child tags to an existing tag.

[wesleywiser]

Visited during wg-debugging triage. DW_TAG_module seems like the better fit for Rust's semantics but we should be careful not to regress consumers if/when we decide to make this change.

[tromey]

FWIW I would probably just close this bug, as the change involves a cost to consumers but no tangible benefit. There's also a chicken-and-egg quality to the rollout of any fix -- like, we'd want to be able to test the gdb patch against the patched rust compiler, but before actually shipping the compiler.