Currently, `llvm-cxxfilt` will strip the leading underscore of its input
on macOS. Historically MachO symbols were prefixed with an extra
underscore and this is why this default exists. However, nowadays, the
`ItaniumDemangler` supports all of the following mangling prefixes:
`_Z`, `__Z`, `___Z`, `____Z`. So really `llvm-cxxfilt` can simply
forward the mangled name to the demangler and let the library decide
whether it's a valid encoding.

Compiling C++ on macOS nowadays will generate symbols with `_Z` and
`___Z` prefixes. So users trying to demangle these symbols will have to
know that they need to add the `-n` prefix. This routinely catches
people off-guard.

This patch removes the `-n` default for macOS and allows calling into
the `ItaniumDemangler` with all the `_Z` prefixes that the demangler
supports (1-4 underscores).

rdar://132714940

Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.

There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.

This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.

Test doesn't pass on mac. See comments on
https://github.com/llvm/llvm-project/pull/75348.

Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.

There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.

Summary:

In AIX OS, function entry label are begin with '.', it can not be decoded currently.
we support to decode the name in this patch for all OS.

Reviewers: Fangrui Song, James Henderson,
Differential Revision: https://reviews.llvm.org/D139864

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lot more cleanups around these APIs. This is
just a start.

Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using `llvm::demangle`. Add a
release note.

Differential Revision: https://reviews.llvm.org/D149104

This was originally a part of D149104 which was backed out. This change
is uncontroversial though, so split it out and reland it.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D152042

I was doing this API conversion to use std::string_view top-down in
D149104, but this exposed issues in individual demanglers that needed to
get fixed first. There's no issue with the conversion for the D language
demangler, so convert it.

I have a more aggressive refactoring of the entire D language demangler
to use std::string_view more extensively, but the interface with
llvm::nonMicrosoftDemangle is the more interesting one.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D151003

I was doing this API conversion to use std::string_view top-down in
D149104, but this exposed issues in individual demanglers that needed to
get fixed first. There's no issue with the conversion for the Rust
demangler, so convert it first.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D149784

D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON) causes
lld/test/wasm/why-extract.s to fail. The reason for this is obscure:

Reason #10007 why std::string_view is dangerous:
Consider the following pattern:

  std::string_view s = ...;
  const char *c = s.data();
  std::strlen(c);

Is c a NUL-terminated C style string? It depends; but if it's not then
it's not safe to call std::strlen on the std::string_view::data().
std::string_view::length() should be used instead.

Fixing this fixes the one lone test that caught this.

microsoftDemangle, rustDemangle, and dlangDemangle should get this same
treatment, too. I will do that next.

Reviewed By: MaskRay, efriedma

Differential Revision: https://reviews.llvm.org/D149675