| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test is not defined.
FAIL: LLVM-Unit :: ADT/./ADTTests/ArrayRefTest.SizeTSizedOperations (178 of 33926)
******************** TEST 'LLVM-Unit :: ADT/./ADTTests/ArrayRefTest.SizeTSizedOperations' FAILED ********************
Note: Google Test filter = ArrayRefTest.SizeTSizedOperations
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ArrayRefTest
[ RUN ] ArrayRefTest.SizeTSizedOperations
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:180:32: runtime error: applying non-zero offset 9223372036854775806 to null pointer
#0 0x5ae8dc in llvm::ArrayRef<char>::slice(unsigned long, unsigned long) const /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:180:32
#1 0x5ae44c in (anonymous namespace)::ArrayRefTest_SizeTSizedOperations_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/unittests/ADT/ArrayRefTest.cpp:85:3
#2 0x928a96 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2474:5
#3 0x929793 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
#4 0x92a152 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
#5 0x9319d2 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
#6 0x931416 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:4257:10
#7 0x920ac3 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
#8 0x920ac3 in main /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50:10
#9 0x7f66135b72e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#10 0x472c19 in _start (/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/unittests/ADT/ADTTests+0x472c19)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:180:32 in
llvm-svn: 374327
|
|
|
|
|
|
|
|
|
| |
llvm-project/llvm/unittests/ADT/ArrayRefTest.cpp:254:25: warning: suggest braces around initialization of subobject [-Wmissing-braces]
std::array<int, 5> A1{42, -5, 0, 1000000, -1000000};
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
{ }
llvm-svn: 372902
|
|
|
|
| |
llvm-svn: 371475
|
|
|
|
|
|
| |
Now that we've dropped VS2015 support (D64326) we can enable these static_asserts on MSVC builds as VS2017+ correctly handles them
llvm-svn: 365471
|
|
|
|
| |
llvm-svn: 358332
|
|
|
|
|
|
| |
This breaks arm self-hosted buildbots.
llvm-svn: 352206
|
|
|
|
| |
llvm-svn: 351954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Differential Revision: https://reviews.llvm.org/D54472
llvm-svn: 351701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
| |
This reverts commit r335839, because it breaks the MSVC build.
llvm-svn: 335844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows the implicit ArrayRef conversions to kick in when e.g.
comparing ArrayRef to a SmallVector.
Reviewers: zturner, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48632
llvm-svn: 335839
|
|
|
|
|
|
| |
We want to check that we can assign to an lvalue here, not a prvalue.
llvm-svn: 324152
|
|
|
|
|
|
|
|
| |
clang OOMs on arm.
This reverts commit a272b2f2ef63f7f602c9ef4d9e10dc4eb9f00aa1.
llvm-svn: 322818
|
|
|
|
|
|
|
|
|
|
| |
Summary: Not sure this needs a review or not. Erring on the safe side.
Reviewers: dblaikie
Differential Revision: https://reviews.llvm.org/D41666
llvm-svn: 322538
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent of the test is to check that array lengths greater than
UINT_MAX work properly. Change the test to stress that scenario, without
triggering pointer overflow UB.
Caught by a WIP pointer overflow checker in clang.
Differential Revision: https://reviews.llvm.org/D33149
llvm-svn: 304353
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26999
llvm-svn: 287722
|
|
|
|
|
|
|
|
|
|
| |
This re-applies r283798, disabled in r283803, with the static_assert
tests disabled under MSVC. The deleted functions still seem to catch
mistakes in MSVC, so it's not a significant loss.
Part of rdar://problem/16375365
llvm-svn: 283935
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r283798, as it causes static asserts on
MSVC 2015 with the following errors:
ArrayRefTest.cpp(38): error C2338: Assigning from single prvalue element
ArrayRefTest.cpp(41): error C2338: Assigning from single xvalue element
ArrayRefTest.cpp(47): error C2338: Assigning from an initializer list
llvm-svn: 283803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this, the following statements will create ArrayRefs that
refer to temporary storage that goes out of scope by the end of the
line:
someArrayRef = getSingleElement();
someArrayRef = {elem1, elem2};
Note that the constructor still has this problem:
ArrayRef<Element> someArrayRef = getSingleElement();
ArrayRef<Element> someArrayRef = {elem1, elem2};
but that's a little harder to get rid of because we want to be able to
use this in calls:
takesArrayRef(getSingleElement());
takesArrayRef({elem1, elem2});
Part of rdar://problem/16375365. Reviewed by Duncan Exon Smith.
llvm-svn: 283798
|
|
|
|
| |
llvm-svn: 280129
|
|
|
|
|
|
|
| |
Reviewed By: majnemer, rnk
Differential Revision: https://reviews.llvm.org/D23965
llvm-svn: 280114
|
|
|
|
|
|
|
|
|
|
| |
The InitializerList test had undefined behavior by creating a dangling pointer to the temporary initializer list. This patch removes the undefined behavior in the test by creating the initializer list directly.
Reviewers: mehdi_amini, dblaikie
Differential Revision: https://reviews.llvm.org/D23890
llvm-svn: 279783
|
|
|
|
|
|
|
|
|
|
| |
Also fix slice wrappers drop_front and drop_back.
The unittests are pretty awkward, but do the job; alternatives
welcome!
..and yes, I do have ArrayRefs with more than 4 billion elements.
llvm-svn: 271546
|
|
|
|
|
|
|
|
| |
We have it for StringRef but not ArrayRef, and ArrayRef has drop_back,
so I see no reason it shouldn't have drop_front. Splitting this out of a
change that I have that will use this funcitonality.
llvm-svn: 268434
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose is to allow templated wrapper to work with either
ArrayRef or any convertible operation:
template<typename Container>
void wrapper(const Container &Arr) {
impl(makeArrayRef(Arr));
}
with Container being a std::vector, a SmallVector, or an ArrayRef.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247214
|
|
|
|
| |
llvm-svn: 244023
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unbreak bots.
For example of mingw-w64-g++-4.8.1,
llvm/unittests/ADT/ArrayRefTest.cpp: In member function 'virtual void {anonymous}::ArrayRefTest_AllocatorCopy_Test::TestBody()':
llvm/unittests/ADT/ArrayRefTest.cpp:56:40: internal compiler error: in count_type_elements, at expr.c:5523
} Array3Src[] = {{"hello"}, {"world"}};
^
Please submit a full bug report,
with preprocessed source if appropriate.
llvm-svn: 244017
|
|
|
|
|
|
|
| |
std::copy does not work for non-trivially copyable classes when we're
copying into uninitialized memory.
llvm-svn: 243995
|
|
|
|
| |
llvm-svn: 239399
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With initializer lists there is a really neat idiomatic way to write
this, 'ArrayRef.equals({1, 2, 3, 4, 5})'. Remove the equal method which
always had a hard limit on the number of arguments. I considered
rewriting it with variadic templates but that's not really a good fit
for a function with homogeneous arguments.
'ArrayRef == {1, 2, 3, 4, 5}' would've been even more awesome, but C++11
doesn't allow init lists with binary operators.
llvm-svn: 230907
|
|
|
|
|
|
| |
initializer lists. Should also silence a -Wsign-compare warning accidentally introduced.
llvm-svn: 229515
|
|
|
|
|
|
| |
values and as function arguments also work as expected.
llvm-svn: 229513
|
|
|
|
|
|
| |
initialization.
llvm-svn: 229512
|
|
|
|
|
|
|
|
| |
MSVC 2013 and GCC. Added a trivial test to ensure the ArrayRef initializer list constructor is called and behaves as expected.
If any of the bots complain (perhaps due to an antiquated version of an STL implementation), I will revert.
llvm-svn: 229502
|
|
|
|
|
|
|
|
|
|
|
| |
ArrayRef<T*> where T is a base of U.
This appears to have broken at least the windows build bots due to
compile errors in the predicate that didn't simply supress the overload.
I'm not sure what the fix is, and the bots have been broken for a long
time now so I'm just reverting until Michael can figure out a fix.
llvm-svn: 225064
|
|
|
|
|
|
| |
where T is a base of U.
llvm-svn: 225053
|
|
|
|
|
|
| |
ArrayRef-of-pointer conversions introduced in r216709
llvm-svn: 216830
|
|
|
|
| |
llvm-svn: 216821
|
|
|
|
| |
llvm-svn: 216008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checking whether the ArrayRef is equal to an explicit list of arguments.
This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.
Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D
llvm-svn: 214041
|
|
|
|
|
|
|
|
| |
The slice(N, M) interface is powerful but not concise when wanting to
drop a few elements off of an ArrayRef, fix this by adding a drop_back
method.
llvm-svn: 212370
|
|
Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:
StringRef myCopy = myStr.copy(myAllocator);
llvm-svn: 200885
|