[libcxxabi][Demangle] Don't drop ctor/dtor name for abi-tagged structures

Before this patch we would demangle abi-tagged structures as follows:
```
$ c++filt -n _ZN1SB5OuterC2Ev
S[abi:Outer]:()

$ c

[libcxxabi][Demangle] Don't drop ctor/dtor name for abi-tagged structures

Before this patch we would demangle abi-tagged structures as follows:
```
$ c++filt -n _ZN1SB5OuterC2Ev
S[abi:Outer]:()

$ c++filt -n _ZN1SB5OuterD2Ev
S[abi:Outer]::~()
```

This is because `Node::getBaseName` was unimplemented for the
`AbiTagAttr` node, which meant that when we tried printing `CtorDtorName`
where its `Basename` `Node` was an `AbiTagAttr`, we'd drop the
name.

Addresses https://github.com/llvm/llvm-project/issues/61213

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

show more ...

[libc++] Move constexpr <cstring> functions into their own headers and remove unused <cstring> includes

Reviewed By: ldionne, Mordante, #libc, #libc_abi

Spies: libcxx-commits

Differential Revision

[libc++] Move constexpr <cstring> functions into their own headers and remove unused <cstring> includes

Reviewed By: ldionne, Mordante, #libc, #libc_abi

Spies: libcxx-commits

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

show more ...

[demangler] No need to space adjacent template closings

With the demangler parenthesizing 'a >> b' inside template parameters,
because C++11 parsing of >> there, we don't really need to add spaces
b

[demangler] No need to space adjacent template closings

With the demangler parenthesizing 'a >> b' inside template parameters,
because C++11 parsing of >> there, we don't really need to add spaces
between adjacent template arg closing '>' chars. In 2022, that just
looks odd.

Reviewed By: MaskRay

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

show more ...

[demangler] Fold expressions of .* and ->*

(Exitingly) a fold expression's operators include .* and ->*, but we
failed to demangle them as we categorize those as MemberExprs, not
BinaryExprs.

Revie

[demangler] Fold expressions of .* and ->*

(Exitingly) a fold expression's operators include .* and ->*, but we
failed to demangle them as we categorize those as MemberExprs, not
BinaryExprs.

Reviewed By: dblaikie

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

show more ...

[demangler] Fix demangling a template argument which happens to be a null pointer

As seen in https://github.com/llvm/llvm-project/issues/51854
llvm-cxxfilt was having trouble demangling the case "_Z

[demangler] Fix demangling a template argument which happens to be a null pointer

As seen in https://github.com/llvm/llvm-project/issues/51854
llvm-cxxfilt was having trouble demangling the case "_Z1fIDnLDn0EEvv".
We handled the "LDNE" case and "LPi0E" but not "LDn0E". This change adds
that handling.

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

show more ...

[demangler] Support C23 _BitInt type

Reviewed By: #libc_abi, aaron.ballman, urnathan

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

[demangler] Fix undocumented Local encoding

GCC emits [some] static symbols with an 'L' mangling, which we attempt
to demangle. But the module mangling changes have exposed that we
were doing so at

[demangler] Fix undocumented Local encoding

GCC emits [some] static symbols with an 'L' mangling, which we attempt
to demangle. But the module mangling changes have exposed that we
were doing so at the wrong level. Such manglings are outside of the
ABI as they are internal-linkage, so a bit of reverse engineering was
needed. This adjusts the demangler along the same lines as the
existing gcc demangler (which is not yet module-aware). 'L' is part
of an unqualified name. As before we merely parse the 'L', and then
ignore it.

Reviewed By: iains

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

show more ...

[demangler] Parenthesize >> inside template args

Both > and >> expressions need to be parenthesized inside template
argument lists.

Reviewed By: dblaikie, rjmccall

Differential Revision: https://r

[demangler] Parenthesize >> inside template args

Both > and >> expressions need to be parenthesized inside template
argument lists.

Reviewed By: dblaikie, rjmccall

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

show more ...

Demangle: Fix crash-on-invalid demangling of a module name with no underlying entity

[demangler] Add operator precedence

The demangler had no concept of operator precendence, and would
parenthesize many more subexpressions than necessary. In particular
it would parenthesize primary

[demangler] Add operator precedence

The demangler had no concept of operator precendence, and would
parenthesize many more subexpressions than necessary. In particular
it would parenthesize primary-expressions, such as '4', which just
looks strange. It would also parenthesize '>' expressions, just in
case they were inside a template parameter list.

This patch fixes both issues.

* Add operator precedence to the OpInfo structure, and add a
subexpression helper that will parenthesize a lower precedence
subexpression.

* Add a 'greater-than is greater-than' indicator to the output buffer,
so the expression printer knows whether it is immediately inside a
template parameter list (and must therefore parenthesize 'expr >
expr'). This is a counter, so that ...

* Add open and close printers to the output buffer, that increment and
decrement the gt-is-gt indicator.

* Parenthesize comma operators inside comma-separated lists. (probably
a rare case, but still).

This dramatically reduces the extraneous parentheses being printed.

Reviewed By: dblaikie, bruno

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

show more ...

[demangler] Add support for C++20 modules

Add support for module name demangling. We have two new demangler
nodes -- ModuleName and ModuleEntity. The former represents a module
name in a hierarchic

[demangler] Add support for C++20 modules

Add support for module name demangling. We have two new demangler
nodes -- ModuleName and ModuleEntity. The former represents a module
name in a hierarchical fashion. The latter is the combination of a
(name) node and a module name. Because module names and entity
identities use the same substitution encoding, we have to adjust the
flow of how substitutions are handled, and examine the substituted
node to know how to deal with it.

Reviewed By: dblaikie

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

show more ...

[demangler] Add co_await demangling

The demangler doesn't understand 'aw' as an operator name. This adds
the necessary smarts -- you may use this as an operator functionname,
but not as an expressio

[demangler] Add co_await demangling

The demangler doesn't understand 'aw' as an operator name. This adds
the necessary smarts -- you may use this as an operator functionname,
but not as an expression operator.

Reviewed By: ChuanqiXu

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

show more ...

[demangler] Reorder parseNestedName loop

parseNestedName's main loop allowed parsing a grammar that was more
flexible than the actual grammar. This refactors that to rule out
some more incorrect ma

[demangler] Reorder parseNestedName loop

parseNestedName's main loop allowed parsing a grammar that was more
flexible than the actual grammar. This refactors that to rule out
some more incorrect manglings.

1) The 'L' extension only applies to unqualified-name components, so
check it just there.

2) The 'M' suffix is, AFAICT, removed from the grammar. Rather than
eliminate it, let's parse it after we've parsed a component.

Added some additional bad mangling tests, which are now rejected.

I don't break the 'T' and 'D[tT]' cases out of the loop, even though
they can only appear at first position, as it seems simpler to just
check there is nothing SoFar.

Reviewed By: ChuanqiXu

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

show more ...

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

show more ...

[demangler] Fix new/delete demangling

I discovered some demangler problems:

a) parsing of new expressions was broken, ignoring any 'gs' prefix
b) (when #a is fixed) badly formatted global new expre

[demangler] Fix new/delete demangling

I discovered some demangler problems:

a) parsing of new expressions was broken, ignoring any 'gs' prefix
b) (when #a is fixed) badly formatted global new expressions
c) formatting of new and delete failed to correctly add whitespace

(a) happens as parseExpr swallows the 'gs' prefix but doesn't pass it
to 'parseNewExpr'. It seems simpler to me to just code the new
expression parsing directly in parseExpr, as is done for delete
expressions.

(b) global new should be rendered something like '::new T' not
'::operator new T'

(c) is resolved by being a bit more careful with whitespace.

Best shown with some examples (don't worry that these symbols are for
impossible instantiations, that's not the point):

Old behaviour:
build/bin/llvm-cxxfilt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<new int, new[] int(4)>() // No ::new
void Fn<new (4u)int, new[] (4u)int(4)>() // No ::new, poor whitespace
void Fn<::delete4, delete[] 4>() // missing necessary space
void Fn<delete4u, ::delete[] 4u>() // missing necessary space

New behaviour:
build/bin/llvm-cxxfilt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<::new int, new[] int(4)>()
void Fn<new(4u) int, ::new[](4u) int(4)>()
void Fn<::delete 4, delete[] 4>()
void Fn<delete 4u, ::delete[] 4u>()

Binutils' behaviour:
c++filt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<::new int, new int(4)>()
void Fn<new (4u) int, ::new (4u) int(4)>()
void Fn<::delete (4), delete[] (4)>()
void Fn<delete (4u), ::delete[] (4u)>()

The new and binutils demanglings are the same modulo some whitespace and optional parens.

Reviewed By: ChuanqiXu

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

show more ...

[demangler] Improve ->* & .* demangling

The demangler treats ->* as a BinaryExpr, but .* as a MemberExpr.
That's inconsistent. This makes the former a MemberExpr too.
However, in order to not regre

[demangler] Improve ->* & .* demangling

The demangler treats ->* as a BinaryExpr, but .* as a MemberExpr.
That's inconsistent. This makes the former a MemberExpr too.
However, in order to not regress the paren output, MemberExpr::print
is modified to parenthesize the MemberExpr if the operator ends with
'*'. Printing is affected thusly:

Before:
obj.member
obj->member
obj.*member
(obj) ->* (member)

After:
obj.member # Unchanged
obj->member # Unchanged
obj.*(member) # Added paren member operand
obj->*(member) # Removed paren on object operand, less whitespace

The right solution to the paren problem is to add some notion of
precedence (and associativity) to Nodes, but that's a larger change
that would become simpler once the refactoring I'm doing is completed.

FWIW, binutils' demangler's paren algorithm has a small idea of
precedence, and will generally not emit parens when the operand is
unary.

Reviewed By: bruno

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

show more ...

[demangler] Stricter NestedName parsing

The parsing of nested names is a little lax. This corrects that.

1) The 'L' local name prefix cannot appear before a NestedName -- only
within it. Let's re

[demangler] Stricter NestedName parsing

The parsing of nested names is a little lax. This corrects that.

1) The 'L' local name prefix cannot appear before a NestedName -- only
within it. Let's remove that check from parseName, and then adjust
parseUnscopedName to allow it with or without the 'St' prefix.

2) In a nested name, a <template-param>, <decltype> or <substitution>
can only appear as the first element. Let's enforce that. Note I do
not remove these from the loop, to make the change easier to follow
(such a change will come later).

3) Given that, there's no need to special case 'St' outside of the
loop, handle it with the other 'S' elements.

4) There's no need to reset 'EndsWithTemplateArgs' after each
non-template-arg component. Rather, always clear it and then set it
in the template-args case.

5) An template-args cannot immediately follow a template-args.

6) The parsing of a CDtor name with ABITags would attach the tags to
the NestedName node, rather than the CDTor node. This is different to
how ABITags are attached to an unscopedName. Make it consistent.

7) We remain with only CDTor and UnscopedName requireing construction
of a NestedName, so let's drop the PushComponent lambda.

8) Add some tests to catch the new rejected manglings.

Reviewed By: ChuanqiXu

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

show more ...

[demangler] Fix unresolvedname demangling

We were dropping the [gs] modifier by parsing it in parseExpr, but not
forwarding it on to parseUnresolvedName. This is the straightforwards
fix to forward

[demangler] Fix unresolvedname demangling

We were dropping the [gs] modifier by parsing it in parseExpr, but not
forwarding it on to parseUnresolvedName. This is the straightforwards
fix to forward that flag -- parseExpr must see past it.

Reviewed By: ChuanqiXu

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

show more ...

[demangler] improve test harness

The demangler test harness is a little unclear. The failed demangling
message always causes me to think about 'reality', changing to a
simple 'Found' seems clearer.

[demangler] improve test harness

The demangler test harness is a little unclear. The failed demangling
message always causes me to think about 'reality', changing to a
simple 'Found' seems clearer.

The expected-to-fail tests abort as soon as one passes, rather than
continue, and then abort if any passed. This changes that loop to
fail at the end, in a similar manner to the expected-to-work loop.

Reviewed By: ChuanqiXu

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

show more ...

[demangler][NFC] Refactor some parsing

There's some unnecessary code duplication in the parser. This
refactors that and deploys boolean variables to avoid the duplication.
These also happen to help

[demangler][NFC] Refactor some parsing

There's some unnecessary code duplication in the parser. This
refactors that and deploys boolean variables to avoid the duplication.
These also happen to help adding module demangling (with an updated
mangling scheme).

1a) The grammar requires some lookahead concerning <template-args>. We
may discover an <unscoped-name> is actually <unscoped-template-name>
<template-args>. (When <unscoped-name> was a substitution, there must
be a following <template-args>.) Refactor parseName to only have one
code path looking for the 'I' indicating <template-args>.

1b) While there I altered the control flow to hold the result in a
variable, rather than tail call. Made it easier to debug (and of
course an optimizer will DTRT here anyway).

2a) An <unscoped-name> can have an St or StL prefix. No need for
completely separate code paths handling the following unqualified-name
though.

2b) Also no need to look for both 'St' and 'StL' separately. Look for
'St' and then conditionally swallow an 'L'.

3) We get a similar issue as #1a when parsing a typeName. Here I just
change the control flow slightly to bring the 'break' out to the end
of the 'S' block and embed the early return inside an if. That's more
in keeping with the code style.

4) Although NFC, there's a new testcase as that's not covered by the
existing demangler tests and is significant in the #1a case above.

Reviewed By: ChuanqiXu

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

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[demangle] Support for ISO/IEC TS 18661 binary floating point type

Reviewed By: #libc_abi, ldionne

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

[libc++abi] Fix possible infinite loop in itanium demangler

A libfuzzer run has discovered some inputs for which the demangler does
not terminate. When minimized, it looks like this: _Zcv1BIRT_EIS1_

[libc++abi] Fix possible infinite loop in itanium demangler

A libfuzzer run has discovered some inputs for which the demangler does
not terminate. When minimized, it looks like this: _Zcv1BIRT_EIS1_E

Deciphered:

_Z
cv - conversion operator

* result type
1B - "B"
I - template args begin
R - reference type <.
T_ - forward template reference | *
E - template args end | |
| |
* parameter type | |
I - template args begin | |
S1_ - substitution #1 * <'
E - template args end

The reason is: template-parameter refs in conversion operator result type
create forward-references, while substitutions are instantly resolved via
back-references. Together these can create a reference loop. It causes an
infinite loop in ReferenceType::collapse().

I see three possible ways to avoid these loops:

1. check if resolving a forward reference creates a loop and reject the
invalid input (hard to traverse AST at this point)
2. check if a substitution contains a malicious forward reference and
reject the invalid input (hard to traverse AST at this point;
substitutions are quite common: may affect performance; hard to
clearly detect loops at this point)
3. detect loops in ReferenceType::collapse() (cannot reject the input)

This patch implements (3) as seemingly the least-impact change. As a
side effect, such invalid input strings are not rejected and produce
garbage, however there are already similar guards in
`if (Printing) return;` checks.

Fixes https://llvm.org/PR51407

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

show more ...

[runtimes] Simplify how we specify XFAIL & friends based on the triple

Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the tripl

[runtimes] Simplify how we specify XFAIL & friends based on the triple

Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.

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

show more ...

Save/restore OuterTemplateParams in AbstractManglingParser::parseEncoding.

Previously we were only saving plain TemplateParams.

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