mangling_v0: Skip extern blocks during mangling

[petrochenkov]

There's no need to include the dummy Nt into the symbol name, items in extern blocks belong to their parent modules for all purposes except for inheriting the ABI and attributes.

Follow up to #92032

(There's also a drive-by fix to the rust-demangler tool's tests, which don't run on CI, I initially attempted using them for testing this PR.)

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

Hm, let's r? @wesleywiser perhaps? I'm not sure what our stability implications for v0 mangling are, though in general this seems fine to me.

[petrochenkov]

The mangling format itself doesn't seem to change, we should only drop some empty segments from it.

[wesleywiser]

Yeah, this seems fine. I can't think of any reason we would want or need to have an empty segment for the extern block in the mangled name (or that there would be stability implications from this change).

@bors r+

[bors]

📌 Commit 6bbbaf9 has been approved by wesleywiser

[ehuss]

@bors r-

#92659 (comment)

[petrochenkov]

@bors r=wesleywiser

[bors]

📌 Commit 333a5cc has been approved by wesleywiser

[eddyb]

@petrochenkov Isn't this a collision hazard?

If hygiene 2.0 can cause the same name to appear twice in a module, those two instances will have distinct DefPaths because the second one will have a disambiguator of 1 instead of 0.

But if one of them is extern { type }, then the DefPaths will be foo::Foo vs foo::{foreign module}::Foo (though printed as foo::Foo), both of which would have a disambiguator of 0.

So either the DefPath should not have the ForeignMod components (kind of like that old idea of desugaring extern "ABI" { fn foo(); } to something like extern "ABI" foreign_fn foo(); in HIR), or this PR needs to be reverted (ideally hygiene 2.0 lets us write tests for collisions solved only by disambiguators).

[petrochenkov]

@eddyb
Yes, you are right, this can cause collisions and needs to be reverted.

Previously 't' with empty name happened to not collide with anything else in type namespace.
But maybe it would be better to reserve a separate letter for extern blocks (if there are enough free letters).

[eddyb]

Oh yeah, I agree, t is not a good idea either - AFAICT all the lowercase namespaces (i.e. not guaranteed to mean anything in particular, and up for grabs for internal use) are declared here, and e.g. f is free:

rust/compiler/rustc_symbol_mangling/src/v0.rs

Lines 782 to 787 in a7d6408

	DefPathData::TypeNs(_) => 't',
	DefPathData::ValueNs(_) => 'v',
	DefPathData::ClosureExpr => 'C',
	DefPathData::Ctor => 'c',
	DefPathData::AnonConst => 'k',
	DefPathData::ImplTrait => 'i',

That is, the only other namespaces I could find are both uppercase (S for shims and I for impls).

In any case, namespaces (whether lowercase or uppercase) do not share encoding space with any other syntax, so most letters aren't used yet - this is intentional, to avoid running into issues if rustc decides to need a lot more namespaces for whatever reason (and if we somehow run out of all 52 of them, we can always shove extra information into the low bits of disambiguators, as unelegant as that is).