| Age | Commit message (Collapse) | Author |
|---|
|
This got exposed when processing large LTO-generated files leading to
crashes.
|
|
On a few compilers (clang 11/12 for example [1]), the following does not
result in a copy elision, and since `Error`'s copy dtor is elided,
results in a compile error:
```
Expect<Something> foobar() {
...
if (Error E = aCallReturningError())
return E;
...
}
```
Moving `E` would, conversely, result in the pessimizing-move warning on
more recent clangs ("moving a local object in a return statement
prevents copy elision")
We just need to make the `Expected` ctor taking an `Error` take it as a
r-value reference.
[1] https://lab.llvm.org/buildbot/#/builders/54/builds/10505
|
|
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
Commit 4a794d848ce81f41c6e23a4d3d3f70c2d7d1baa4 caused build failure with -Werror -Wpessimizing-move on the clang-ppc64-aix buildbot. This patch applies Clang's suggestion to remove `std::move`.
|
|
Differential Revision: https://reviews.llvm.org/D119307
|
|
Instead of simply assuming that it will be zero. I double checked
that the bitstream reader doesn't have any special handling for
all-zero blobs, it will always write out the full contents.
|
|
If we're trying to reserve more memory than bits in the stream,
reject this early to avoid OOM.
|
|
Avoid report_fatal_error(), propagate the error upwards instead.
|
|
This code clearly intended to forward the error, but instead
returned the non-error result.
|
|
Use proper error reporting instead of report_fatal_error().
|
|
|
|
I was recently debugging a similar issue to https://reviews.llvm.org/D86500 only with a large metadata section. Only after I finished debugging it did I discover it was fixed very recently.
My version of the fix was going to alignTo since that uses uint64_t and improves the readability of the code. So I though I would go ahead and share it.
Differential Revision: https://reviews.llvm.org/D86957
|
|
strtab are of size > 2^29
This happens when using -flto and -Wl,--plugin-opt=emit-llvm to create a linked LTO bitcode file, and the bitcode file has a strtab with size > 2^29.
All the issues relate to a pattern like this
size_t x64 = y64 + z32 * C
When z32 is >= (2^32)/C, z32 * C overflows.
Reviewed-by: MaskRay
Differential Revision: https://reviews.llvm.org/D86500
|
|
|
|
The build failed with
error: call to deleted constructor of 'llvm::Error'
errors.
This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
|
|
|
|
|
|
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.
This is needed to avoid a circular dependency when using the bitstream
code for parsing optimization remarks.
Since Bitcode uses Core for the IR part:
libLLVMRemarks -> Bitcode -> Core
and Core uses libLLVMRemarks to generate remarks (see
IR/RemarkStreamer.cpp):
Core -> libLLVMRemarks
we need to separate the Bitstream and Bitcode part.
For clang-doc, it seems that it doesn't need the whole bitcode layer, so
I updated the CMake to only use the bitstream part.
Differential Revision: https://reviews.llvm.org/D63899
llvm-svn: 365091
|
