3 ms·

I don't know if does not have the worst looking code in the world, but in my opinion it is far far worst that what I can bear with. It should die, the sooner th

by Joky 10y ago

I don't know if does not have the worst looking code in the world, but in my opinion it is far far worst that what I can bear with. It should die, the sooner the better, and we'll be happy for anyone to provide a replacement. If this wasn't written in Rust I'd adopt it in LLVM!

kbenson 10y ago
That brings up an interesting question, since it sounds like you might have some inside information: Is LLVM amenable to using a library for this functionality, or is it considered something which must be maintained in-project? I ask because at the point that something is compiled to a library, the source implementation shouldn't really matter (ignoring silly things like embedding a VM), so at that point this being implemented in Rust shouldn't matter too much (beyond it possibly being less familiar to the LLVM devs). Not that I'm actually advocating for that at this point. This is a new library, and as stated in the blog still has some differences in output compared to other similar libraries.
- Joky 10y ago
  You have to understand that one of LLVM goal is to provide a full toolchain, through reusable library components. So we're seeking to provide our own solution for this, and we're actually providing this feature as a library for a long time. If you're on macOS, it is the default libc++-abi and you can have it available on any macOS system: $ nm /usr/lib/libc++abi.dylib | grep cxa_demangle 00000000000018e0 T ___cxa_demangle Which means you can compile the following c++ file with clang++ and gets demangling from the system: #include <iostream> extern "C" char *__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status); int main() { std::cout << "Demangled: " << __cxa_demangle("_Z17GetExecutablePathPKcb", nullptr, nullptr, nullptr) << "\n"; } We need a great demangler in LLVM because we're using it in the LLDB debugger for instance. The LLVM one is quite slow actually, if anyone is interested in writing a (clean) very performant C++ one within LLVM, I'm volunteering to help the review and integration :) (edit: formatting)
  - kbenson 10y ago
    > You have to understand that one of LLVM goal is to provide a full toolchain, through reusable library components Fair enough, that makes sense. If you are aiming to be a full toolchain, it's useful to have it in-project. Edit: Whoops! s/fool/full/
masklinn 10y ago
> If this wasn't written in Rust I'd adopt it in LLVM! Would it be possible to translate the Rust code into C++ and thus basically get the Rust safety in C++?
- adrianN 10y ago
  Revive the C backend to LLVM that was discontinued in 2012 for being too buggy and compile Rust straight to C.
  - masklinn 10y ago
    LLVM is coded in C++, and C++ has higher-level constructs to which Rust constructs should be relatively easy to map safely and with a readable end result.

by Joky 10y ago

kbenson 10y ago

That brings up an interesting question, since it sounds like you might have some inside information: Is LLVM amenable to using a library for this functionality, or is it considered something which must be maintained in-project? I ask because at the point that something is compiled to a library, the source implementation shouldn't really matter (ignoring silly things like embedding a VM), so at that point this being implemented in Rust shouldn't matter too much (beyond it possibly being less familiar to the LLVM devs). Not that I'm actually advocating for that at this point. This is a new library, and as stated in the blog still has some differences in output compared to other similar libraries.

Joky 10y ago
You have to understand that one of LLVM goal is to provide a full toolchain, through reusable library components. So we're seeking to provide our own solution for this, and we're actually providing this feature as a library for a long time. If you're on macOS, it is the default libc++-abi and you can have it available on any macOS system: $ nm /usr/lib/libc++abi.dylib | grep cxa_demangle 00000000000018e0 T ___cxa_demangle Which means you can compile the following c++ file with clang++ and gets demangling from the system: #include <iostream> extern "C" char *__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status); int main() { std::cout << "Demangled: " << __cxa_demangle("_Z17GetExecutablePathPKcb", nullptr, nullptr, nullptr) << "\n"; } We need a great demangler in LLVM because we're using it in the LLDB debugger for instance. The LLVM one is quite slow actually, if anyone is interested in writing a (clean) very performant C++ one within LLVM, I'm volunteering to help the review and integration :) (edit: formatting)
- kbenson 10y ago
  > You have to understand that one of LLVM goal is to provide a full toolchain, through reusable library components Fair enough, that makes sense. If you are aiming to be a full toolchain, it's useful to have it in-project. Edit: Whoops! s/fool/full/

masklinn 10y ago

> If this wasn't written in Rust I'd adopt it in LLVM! Would it be possible to translate the Rust code into C++ and thus basically get the Rust safety in C++?

adrianN 10y ago
Revive the C backend to LLVM that was discontinued in 2012 for being too buggy and compile Rust straight to C.
- masklinn 10y ago
  LLVM is coded in C++, and C++ has higher-level constructs to which Rust constructs should be relatively easy to map safely and with a readable end result.