rustc_symbol_mangling: support structural constants and &str in v0.

[eddyb]

This PR should unblock #85530 (except for float const generics, which AFAIK should've never worked).
(cc @tmiasko could the #85530 (comment) failures be retried with a quick crater "subset" run of this PR + changing the default to v0? Just to make sure I didn't miss anything other than the floats)

The encoding is the one suggested before in e.g. #61486 (comment), tho this PR won't by itself finish #61486, before closing that we'd likely want to move to @oli-obk's "valtrees" (i.e. #83234 and other associated work).

---

EDITs:

1. switched unit/tuple/braced-with-named-fields <const-fields> prefixes from "u"/"T"/"" to "U"/"T"/"S" to avoid the ambiguity reported by @tmiasko in rustc_symbol_mangling: support structural constants and &str in v0. #87194 (comment).

2. rustc-demangle PR: v0: demangle structural constants and &str. rustc-demangle#55

3. RFC amendment PR: [RFC2603] Extend <const> to include str and structural constants. rfcs#3161

   • also removed the grammar changes included in that PR, from this description

4. added tests (temporarily using my fork of rustc-demangle)

---

r? @michaelwoerister

[michaelwoerister]

Nice! Thanks for moving on that so quickly, @eddyb! For reference, here is a link to the current grammar: https://github.com/rust-lang/rfcs/blob/master/text/2603-rust-symbol-name-mangling-v0.md#syntax-of-mangled-names

[michaelwoerister]

And here is the relevant part of the grammar that this PR will supersede:

<const> = <type> <const-data>
        | "p" // placeholder, shown as _
        | <backref>

// The encoding of a constant depends on its type. Integers use their value,
// in base 16 (0-9a-f), not their memory representation. Negative integer
// values are preceded with "n". The bool value false is encoded as `0_`, true
// value as `1_`. The char constants are encoded using their Unicode scalar
// value.
<const-data> = ["n"] {<hex-digit>} "_"

[michaelwoerister]

This looks great!

So now we just need support for this to land in rustc-demangle so that we can add test cases, right?

[tmiasko]

I extended LLVM Rust demangler with support for proposed grammar. Apart from issue with u in <const-fields>, everything else seems good to me. Special casing &str to avoid printing &*".." was easy enough.

Since you are also updating the test cases here. I remember having to change the src/test/codegen/vec-shrink-panic.rs when enabling v0 by default. Is this no longer the case?

[michaelwoerister]

The first and third production can start with u because of Punycode encoded identifiers.

Great catch, @tmiasko!

[pcwalton]

What remains to be done here? Can I help move this along somehow?

[michaelwoerister]

If I understand correctly the sequence for making progress here is:

• Add support for the grammar additions to https://github.com/alexcrichton/rustc-demangle
• Update rustc's version of rustc-demangle
• Add test cases for the things added here to https://github.com/rust-lang/rust/tree/master/src/test/ui/symbol-names
• Make the new mangling scheme the default (which will also give us more testing of the changes here in the wild)
• Amend the RFC with the grammar changes

Does that sound right, @eddyb & @tmiasko?

EDIT: Only the first three steps are needed to merge this PR.

[eddyb]

Apologies for not leaving a comment with the status, I've had an in-progress rustc-demangle branch (with necessary prerequsites - though I've landed some of them separately already - and the hardest parts like str demangling) for the past week or two, I've only not submitted yet because a few other things came up. I'll try to wrap it up soon.

[eddyb]

Demangling PR up at rust-lang/rustc-demangle#55 - next step is submitting the RFC amendment, I'll try to get to that later today.

[eddyb]

I've opened the RFC amendment PR (rust-lang/rfcs#3161 - should someone FCP it?) and just pushed a few commits with symbol-names tests.

We've already done a crater run through #85530, so I think we're only blocked on the RFC amendment (and reviews, I guess? if any are left).

[michaelwoerister]

From my point of view this looks good to go! Maybe @oli-obk wants to have a closer look at the interactions with const-eval?

[oli-obk]

@bors r=michaelwoerister,oli-obk

[bors]

📌 Commit b4fcf1b has been approved by michaelwoerister,oli-obk

[eddyb]

@bors rollup=never

[bors]

⌛ Testing commit b4fcf1b with merge 707a1c4d93cbf4ad2886d4327d8d9be3bae4a76a...

[bors]

💔 Test failed - checks-actions

[eddyb]

Hopefully #87194 (comment) is fixed by the new commit to compiletest.

@bors r=michaelwoerister,oli-obk

[bors]

📌 Commit 24526bb has been approved by michaelwoerister,oli-obk

[bors]

⌛ Testing commit 24526bb with merge ad02dc4...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister,oli-obk
Pushing ad02dc4 to master...