Alex Crichton

I believe this is now in-tree, so I'm going to close this

FWIW the support so far I feel has been fantastic. We've ironed out a few things wrt to the build image (making sure to fuzzers are optimized, making sure optimizations...

@inferno-chromium awesome progress! On the topic of symbols, currently rustc uses a C++-like name-mangling scheme but doesn't match it entirely. What rustc does it has a bunch of path components...

Unfortunately the hash cannot be turned off, it's required for correctness to link libraries together in rustc. The compiler assumes it's there to ensure that two same-named libraries linked together...

Symbol mangling changes are tracked at https://github.com/rust-lang/rust/issues/60705. I don't currently know the intentions of the compiler team about preserving an option to opt-in to the old scheme.

The project AFAIK hasn't blessed something as an official demangler, but rustc-demangle is as close as anything can be to being official without actually being official. It's used by the...

If it's helpful that crate also has a [C API](https://github.com/alexcrichton/rustc-demangle/blob/master/crates/capi/include/rustc_demangle.h) for calling into the demangler.

For the binary encoding, here's another possible encoding: ``` importname' ::= 0x00 len: in: => in (if len = |in|) | 0x01 len: in: => "${in.name}@N" (if len = |in|,...

I agree yeah there's risk since the name in the binary format is "so simple", but yeah that's also where I'd hope that tests could weed things out. It'd be...

Ah I see! So something like (as a transition to the future): ``` importname' ::= 0x00 len: in: => in (if len = |in|) | 0x01 len: in: => "${in.name}@${in.canonver}"...