Ping: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01469.html
On Wed, Sep 25, 2019, at 8:25 PM, Eduard-Mihai Burtescu wrote: > The main change here is in the treatment of $...$ escapes. > I've relaxed the treatment of unknown escapes, during > unescaping, to continue processing the input string, > leaving the remainder of current path segment as-is. > Relatedly, rust_is_mangled function doesn't check escapes > at all anymore (as unknown escapes aren't errors now). > > E.g. "a$LT$b$X$c$GT$::d$C$e" would now be demangled to > "a<b$X$c$GT$::d,e" ($X$ not being a valid escape), > instead of being treated as an invalid Rust symbol. > > This behavior matches the official Rust demangler, the > intention being that this more gracefully handles new > escapes being added to the legacy mangling format. > > The other change is allowing the hash at the end of the > Rust symbol to have all 16 of the possible hex nibbles. > Previously the maximum was 15, as a permutation of all > 16 hex nibbles was considered highly unlikely, but I > stumbled across this example in my large (1M) data set: > "_ZN4core3ptr18real_drop_in_place17h8abe3105492df6c7E" > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Also, I have no commit access, so I'd be thankful if > someone would commit this for me if/once approved. > > 2019-09-25 Eduard-Mihai Burtescu <ed...@lyken.rs> > libiberty/ChangeLog: > * rust-demangle.c (looks_like_rust): Remove. > (rust_is_mangled): Don't check escapes. > (is_prefixed_hash): Allow 0-9a-f permutations. > (rust_demangle_sym): Don't bail on unknown escapes. > * testsuite/rust-demangle-expected: Update 'main::$99$' test.
