Tracking issue for RFC 2526, "Support underscores as constant names"

[Centril]

This is a tracking issue for the RFC "Support underscores as constant names" (rust-lang/rfcs#2526).

Steps:

• Implement the RFC – Support underscore as constant name #55015
• Implement static _ as well
• Adjust documentation (see instructions on forge)
  • Document underscore_const_names reference#620
• Stabilization PR (see instructions on forge)
  • Stabilize underscore_const_names in 1.37.0 #61347

Unresolved questions:

None

[petrochenkov]

Ugh, seems like a legitimized hack rather than a... well, any of several proper features to which this can be generalized.

At least this is a very tiny hack.
Implementation strategy is the same as for use Trait as _;.
If we encounter _ instead of the const name identifier, then we create a gensym for it instead of storing it in AST directly (so that different _s do not conflict).
Together with a feature gate and tests that would be all the implementation.

[Centril]

Ugh, seems like a legitimized hack rather than a... well, any of several proper features to which this can be generalized.

Hehe, I agree we should generalize (to patterns) eventually but it seemed that it was much more complex from @eddyb's comments. :)

[dsciarra]

looks interesting, I will give it a try!

[earthengine]

@petrochenkov

Can we also ensure that those gensyms get removed after before codegen? This means, the generated MIR should be removed in some MIR rounds.

[oli-obk]

We don't need to remove any MIR. Unused private constants don't end up in metadata.

[earthengine]

@oli-obk

Fine. There is one "inconsistency" in Rust today:

let _: str = *"123"; //Legal
let _v: str = *"123"; //Illegal unless unsized_rvalues

When implementing this, how do we want to justify

const _: str = *"123";
const _v: str = *"123";

Shall we repeat the inconsistency, or shall we count both valid or invalid?

[oli-obk]

I'd start out with both being disallowed, since that is the current behaviour of constants. But I have no strong opinion.