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
The output buffer has a 'back' member, which returns NUL when you try
it with an empty buffer. But there are no use cases that need that
additional functionality. This makes the 'back' member behave more
like STL containers' back members. (It still returns a value, not a
reference.)
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123201
On Windows on i386, C++ member functions use a different calling
convention (`__thiscall`) than the default one for regular functions
(`__cdecl`). (On Windows on architectures other than i386, both calling
convention attributes are no-ops.)
This matches how libstdc++ declares these types.
This fixes the std/thread/futures/futures.{shared,unique}_future/dtor.pass.cpp
tests on i386 mingw.
Differential Revision: https://reviews.llvm.org/D124990
(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
When the sigreturn trampoline is found the unw_proc_info_t.end_ip need to be set to
indicate a stack frame is found.
Reviewed By: cjdb, #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D124522
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.
Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.
That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.
The buffer reset member function is never used, and is deleted.
The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.
But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122604
Placing a run-once test inside the operator lookup function caused
problems with the thread sanitizer. See D122975.
Break out the operator table into a member variable, and move the test
to the unit test machinery.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123390
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
The underlying TLS destruction order bug has been fixed in the OS. This
would technically still fail when running on top of macOS < 12, however
we don't have a good way of encoding that using Lit features. Indeed,
the existing target=<FOO> Lit feature encodes the deployment target,
not the actual runtime system that the tests are being run on.
If this test starts failing on your machine after this patch, upgrading
to macOS 12 should solve the problem.
The demangler has a utility class 'SwapAndRestore'. That name is
confusing. It's not swapping anything, and the restore part happens at
the object's destruction. What it's actually doing is allowing a
override of some value that is dynamically accessible within the
lifetime of a lexical scope. Thus rename it to ScopedOverride, and
tweak it's member variable names.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122606
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
Both > and >> expressions need to be parenthesized inside template
argument lists.
Reviewed By: dblaikie, rjmccall
Differential Revision: https://reviews.llvm.org/D122474
* Add instantiation tests to ItaniumDemangleTest, to make sure all
match functions provide constructor arguments to the provided functor.
* Fix the Node constructors that lost const qualification on arguments.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122665
In order to add a unit test, we need to expose the node names beyond
ItaniumDemangle.h. This breaks them out into a def file.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122739
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential Revision: https://reviews.llvm.org/D121015
Each demangler node's match function needs to call the provided
functor with constructor arguments. That was omitted from D120905.
This adds the new Precedence argument where necessary (and a missing
boolean for a module node).
The two visitors need updating with a printer for that type, and this
adds a stub to cxa_demangle's version. blaikie added one to llvm's.
I'll fill out those printers in a followup, rather than wait, so that
downstream consumers are unbroken.
This means that re-running with llvm-lit in that configuration will
work as expected. This also enables assertions in libc++abi in the
Generic-assertions CI job, which was disabled previously.
Differential Revision: https://reviews.llvm.org/D122597
The OutputBuffer class tries to present a NUL-terminated string API to
consumers. But several of them would prefer a StringView. In
particular the Microsoft demangler, juggles between NUL-terminated and
StringView, which is confusing.
This adds a StringView conversion, and adjusts the Demanglers that can
benefit from that.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D120990
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
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
In the new-style testing configurations, we were hardcoding paths to the
`include` and `lib` directories, which was incorrect but always went
unnoticed because the hardcoded values always happened to match the
actual value.
When using new-style configs with the bootstrapping build, this falls
appart -- and we never noticed this because the bootstrapping build was
still using old style configs.
This patch removes the %{install} substitution, which makes it too
tempting to hardcode installation paths, and it also switches the
bootstrapping build to actually using new-style configs like we
always intended to do.
Differential Revision: https://reviews.llvm.org/D121700
The fix for D111703 clobbered r4 both to:
- Save/restore the original lr.
- Load the address of _Unwind_Resume for LIBCXXABI_BAREMETAL.
This patch saves and restores lr without clobbering any extra
registers.
For LIBCXXABI_BAREMETAL, it is still necessary to clobber one extra
register to hold the address of _Unwind_Resume, but it seems better to
use ip/r12 (intended for linker veneers/trampolines) than r4 for this
purpose.
The function also clobbers r0 for the _Unwind_Resume function's
parameter, but that is unavoidable.
Reviewed By: danielkiss, logan, MaskRay
Differential Revision: https://reviews.llvm.org/D121432
If LIBCXX_ENABLE_SHARED isn't explicitly set on the cmake command
line, isn't set in the cache, and the libcxxabi project is configured
before libcxx, then LIBCXX_ENABLE_SHARED isn't defined yet. Once
the libcxx cmake project has been parsed, LIBCXX_ENABLE_SHARED would
have been set to its default value of ON.
This makes sure that the symbols are properly dllexported in such
a configuration scenario.
Differential Revision: https://reviews.llvm.org/D120982
In addressing the buffer ownership API, I discovered a rogue member
function that returned by value rather than by reference. It clearly
intended to return by reference, but because the copy ctor wasn't
deleted this wasn't caught.
It is not necessary to make this a move-only type, although that would
be an alternative.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D120901
Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normally get if we included
the headers as user headers.
The goal of the test suite is normally to mirror as closely as possible
how users would use the library. Technically, this change goes against
that philosophy, since users should be using `-isystem` (if they ever
need to specify the libc++ path explicitly, which should be a rare
occurence). However, I believe fishing out additional warnings from
the headers provides more value, hence this change. Ideally, we'd be
able to still use `-isystem`, but instruct Clang to still emit warnings
from the libc++ headers (e.g. we could tell Clang to emit warnings in
any file inside `<...>/usr/include/c++/v1`).
Reviewed By: #libc, ldionne, #libc_abi
Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D118616
Instead, folks can use the equivalent variables provided by CMake
to set those. This removal aims to reduce complexity and potential
for confusion when setting the target triple for building the runtimes,
and make it correct when `CMAKE_OSX_ARCHITECTURES` is used (right now
both `-arch` and `--target=` will end up being passed, which is downright
incorrect).
Differential Revision: https://reviews.llvm.org/D112155
This commit reverts 5aaefa51 (and also partly 7f285f48e7 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.
Differential Revision: https://reviews.llvm.org/D120683
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
We need to parse operator names in 3 places -- expressions, names &
fold expressions. Currently we have 3 separate pieces to do this, and a FIXME.
The operator name and expression parsing are implemented as
handwritten two-character nested switches, the fold expression is a
sequence of string comparisons.
This adds a new OperatorInfo class to encode the operator info
(encoding, kind, name), and has a table that it can binary search.
From that each of the above 3 uses are altered to use the new scheme.
Existing tests cover parsing operator encodings.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119467
Improve demangler buffer hysteresis. If we needed more than double
the buffer, the original code would allocate exactly the amount
needed, and thus consequently the next request would also realloc.
We're very unlikely to get into wanting more than double, after the
first allocation, as it would require the user to have used an
identifier larger than the hysteresis. With machine generated code
that's possible, but unlikely.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119972
The SwapAndRestore class is over engineered. Nothing makes use of the
early restoration machinery. Let's just remove that cognative burdon.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D120673
libc++abi should be responsible for installing its own headers, it
doesn't make sense for libc++ to be responsible for it.
Differential Revision: https://reviews.llvm.org/D101458
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
Differential Revision: https://reviews.llvm.org/D106124
The linter complains about the formatting in subsequent changes.
Fixing that now.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D120117
When building libcxxabi via LLVM_ENABLE_RUNTIMES=libcxxabi the CMake
invocation fails because of missing "unwind" target. However,
if the extraneous dependency is removed, the library builds just fine
against installed libunwind and tests work fine. To fix this,
add the dependency only if the target actually exists.
Differential Revision: https://reviews.llvm.org/D119538
The copy and pristine versions of Utility diverged and one didn't
include <algorithm>. As that's a rather large header, let's just open
code the comparisons.
Reviewed By:
Differential Revision: https://reviews.llvm.org/
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
In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.
Differential Revision: https://reviews.llvm.org/D119264
We added one for libc++ recently, and this patch adds one for libc++abi.
Also, as a fly-by fix, include older libunwind dylibs in the testing of
libc++ and libc++abi, which fixes some issues related to running
back-deployment tests on newer systems.
Differential Revision: https://reviews.llvm.org/D119466
Nathan Sidwell