4f0c568785
Handle non-integer const generic parameters in debuginfo type names. This PR fixes an ICE introduced by https://github.com/rust-lang/rust/pull/85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits. The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value. The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully. I'd be interested in ideas on how to do this better. r? `@wesleywiser` cc `@dpaoliello` (do you see any problems with this approach?) cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?) Fixes https://github.com/rust-lang/rust/issues/86893 |
||
|---|---|---|
| .. | ||
| back | ||
| coverageinfo | ||
| debuginfo | ||
| mir | ||
| traits | ||
| base.rs | ||
| common.rs | ||
| glue.rs | ||
| lib.rs | ||
| meth.rs | ||
| mono_item.rs | ||
| target_features.rs | ||