Debug info for const generics is hashes rather than something nice

[RalfJung]

In #115748 I got a test failure in tests/debuginfo/function-names.rs: function_names::const_generic_fn_non_int<{CONST#ad91263f6d2dd96e}> changed to static fn function_names::const_generic_fn_non_int<{CONST#73a38766b652ae7d}>. That PR leads to some new AllocIds being generated which shifts some IDs around, so it seems like the AllocId are affecting the function name here. @oli-obk was confused by this since with valtrees, shouldn't our function names be stable now? Indeed AllocId are not very stable at all so it seems potentially problematic if they are relevant for function names. The underlying function call is const_generic_fn_non_int::<{ () }> so this is not a very complicated valtree. ;)

Cc @rust-lang/project-const-generics

[RalfJung]

Actually I am seeing the name change in #115803 as well, so it's not some alloc ID change, it's... maybe a slightly different representation of the same const value?

[RalfJung]

Mystery solved! It's this hash right here:

rust/compiler/rustc_codegen_ssa/src/debuginfo/type_names.rs

Lines 664 to 670 in e16a6d0

	_ => {
	// If we cannot evaluate the constant to a known type, we fall back
	// to emitting a stable hash value of the constant. This isn't very pretty
	// but we get a deterministic, virtually unique value for the constant.
	//
	// Let's only emit 64 bits of the hash value. That should be plenty for
	// avoiding collisions and will make the emitted type names shorter.

Now, whether that's expected behavior or not, I cannot say.

[oli-obk]

Ah yea... I guess I should check how we render strings. It's probably an issue if we have symbol names that themselves are multiple megabytes large

[RalfJung]

Does rust-lang/rfcs#3161 fix this? Not sure if v0 mangling is involved and what happens for old-school mangling (or if old-school mangling is even still a thing).

EDIT: The PR doesn't change the relevant test, so I guess the answer is "no". Are there any plans to completely switch to v0 name mangling, or do we need a similar fix for old name mangling?

[michaelwoerister]

FYI: these names are part of debuginfo and not related to symbol mangling. Any change to the debuginfo version of these names should be done with care to make sure we don't break GDB, LLDB, NatVis, etc.

[BoxyUwU]

cc #126060