https://bugs.kde.org/show_bug.cgi?id=431306
--- Comment #6 from Mark Wielaard <m...@klomp.org> ---
(In reply to Mark Wielaard from comment #4)
> OK, so this patch contains:
>
> - An update to the update-demangler script to use gcc git instead svn
> - The result of running the updated script to get an updated demangler
> - A change to long_namespace_xml.stderr.exp because two overly long symbols
> aren't demangled anymore, but just returned as is.
And an update to the m_demangle/demangle.c source to deal with Rust demangling.
Specificly these two changes:
- Rust demangling (0) is only done if C++ demangling (1) succeeds
- because Rust demangling is performed in-place, and it is difficult
- to prove that we "own" the storage -- hence, that the in-place
- operation is safe -- unless it is clear that it has come from the
- C++ demangler, which returns its output in a heap-allocated buffer
- which we can be sure we own. In practice (Nov 2016) this does not
- seem to be a problem, since the Rust compiler appears to apply C++
- mangling after Rust mangling, so we never encounter symbols that
- require Rust demangling but not C++ demangling.
- if (demangled) {
- /* Possibly undo (0). This is the only place where it is
- safe, from a storage management perspective, to
- Rust-demangle the symbol. That's because Rust demangling
- happens in place, so we need to be sure that the storage
- it is happening in is actually owned by us, and non-const.
- In this case, the value returned by ML_(cplus_demangle)
- does have that property. */
- if (rust_is_mangled(demangled)) {
- rust_demangle_sym(demangled);
- }
- *result = demangled;
- } else {
- *result = orig;
- }
So I assume cplus_demangle now directly demangles old and new style rust
symbols?
--
You are receiving this mail because:
You are watching all bug changes.
