[all-commits] [llvm/llvm-project] d3b101: [demangler] Simplify OutputBuffer initialization
Nathan Sidwell via All-commits
all-commits at lists.llvm.org
Mon Oct 17 04:35:10 PDT 2022
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: d3b10150b683142a7481893ddffe9206e1d29f95
https://github.com/llvm/llvm-project/commit/d3b10150b683142a7481893ddffe9206e1d29f95
Author: Nathan Sidwell <nathan at acm.org>
Date: 2022-10-17 (Mon, 17 Oct 2022)
Changed paths:
M libcxxabi/src/cxa_demangle.cpp
M libcxxabi/src/demangle/Utility.h
M llvm/include/llvm/Demangle/Utility.h
M llvm/lib/Demangle/DLangDemangle.cpp
M llvm/lib/Demangle/ItaniumDemangle.cpp
M llvm/lib/Demangle/MicrosoftDemangle.cpp
M llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
M llvm/lib/Demangle/RustDemangle.cpp
Log Message:
-----------
[demangler] Simplify OutputBuffer initialization
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.
Some adjustment to a couple of uses is needed, due to the lazy buffer
creation of this patch.
a) the Microsoft demangler can demangle empty strings to nothing,
which it then memoizes. We need to avoid the UB of passing nullptr to
memcpy.
b) a unit test checks insertion of no characters into an empty buffer.
We need to avoid UB when converting that to std::string.
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
More information about the All-commits
mailing list