Currently libc++ defines operator== and operator!= as friend functions in the
definition of the istream_iterator class template. Such definition has a subtle
difference from an out-of-line definition required by the C++ Standard: these
functions can only be found by argument-dependent lookup, but not by qualified
lookup.
This patch changes the definition, so that it conforms to the C++ Standard and
adds a check involving qualified lookup to the test suite.
Patch contributed by Mikhail Maltsev.
Differential Revision: https://reviews.llvm.org/D40415
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@320363 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes the test suite to attempt and prefer -std=c++17 over
-std=c++1z. It also fixes the REQUIRES and UNSUPPORTED lit markers
to refer to c++17 over c++1z.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@317610 91177308-0d34-0410-b5e6-96231b3b80d8
This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
This performs additional de-uglification, so all of these tests
follow the example of iterator.traits/empty.pass.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@310761 91177308-0d34-0410-b5e6-96231b3b80d8
This makes them consistent (many comments already used uppercase).
The special REQUIRES, UNSUPPORTED, and XFAIL comments are excluded from this change.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@309468 91177308-0d34-0410-b5e6-96231b3b80d8
Creating a function pointer with proper parameters pointing to std::next() or std::prev() should work.
This change moves the invented paramater for enable_if over to the return type to resolve this QoI issue.
Patch by Jason Liu.
Differential Revision: https://reviews.llvm.org/D34649
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@308932 91177308-0d34-0410-b5e6-96231b3b80d8
In C++17, these iterators are allowed but not required
to inherit from the deprecated std::iterator base class.
Fixes D32727.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@302318 91177308-0d34-0410-b5e6-96231b3b80d8
The test is passing with c++11 and c++14 but not c++1z on this
particular version of the compiler. Try to use lit boolean condition
to satisfy this constaint.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296725 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r296712. It broke our bot.
It turns out that the test is passing with c++11 and c++14 but
not c++1z on this particular version of the compiler. Since one
job is defaulting to c++1z and the other is testing all config I'm
not sure how to fix this...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296724 91177308-0d34-0410-b5e6-96231b3b80d8
This tests is failing in XCode 7.0. But Xcode 7.3 that shipped
an updated clang has this test passing. This is fixing green dragon
which runs this configuration.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296712 91177308-0d34-0410-b5e6-96231b3b80d8
No code changes were needed, but I updated a few tests.
Also resolved P0509 and P0521, which required no changes to the library or tests.
This patch was reverted due to llvm.org/PR31016. There is a bug in Clang 3.7
which causes default.pass.cpp to fails. That test is now marked as XFAIL for that
clang version.
This patch was originally authored by Marshall Clow.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289708 91177308-0d34-0410-b5e6-96231b3b80d8
test/std/input.output/iostream.format/input.streams/istream.unformatted/get.pass.cpp
Add static_cast<char> because basic_istream::get() returns int_type (N4606 27.7.2.3 [istream.unformatted]/4).
test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minus1.pass.cpp
Add static_cast<char> because toupper() returns int (C11 7.4.2.2/1).
test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.ops/assign_t.pass.cpp
This test is intentionally writing doubles to ostream_iterator<int>.
It's silencing -Wliteral-conversion for Clang, so I'm adding C4244 silencing for MSVC.
test/std/language.support/support.limits/limits/numeric.limits.members/infinity.pass.cpp
Given `extern float zero;`, the expression `1./zero` has type double, which emits a truncation warning
when being passed to test<float>() taking float. The fix is to say `1.f/zero` which has type float.
test/std/numerics/complex.number/cmplx.over/arg.pass.cpp
test/std/numerics/complex.number/cmplx.over/norm.pass.cpp
These tests were constructing std::complex<double>(x, 0), emitting truncation warnings when x is long long.
Saying static_cast<double>(x) avoids this.
test/std/numerics/rand/rand.eng/rand.eng.lcong/seed_result_type.pass.cpp
This was using `int s` to construct and seed a linear_congruential_engine<T, stuff>, where T is
unsigned short/unsigned int/unsigned long/unsigned long long. That emits a truncation warning in the
unsigned short case. Because the range [0, 20) is tiny and we aren't doing anything else with the index,
we can just iterate with `T s`.
test/std/re/re.traits/value.pass.cpp
regex_traits<wchar_t>::value()'s first parameter is wchar_t (N4606 28.7 [re.traits]/13). This loop is
using int to iterate through ['g', 0xFFFF), emitting a truncation warning from int to wchar_t
(which is 16-bit for some of us). Because the bound is exclusive, we can just iterate with wchar_t.
test/std/strings/basic.string/string.cons/size_char_alloc.pass.cpp
This test is a little strange. It's trying to verify that basic_string's (InIt, InIt) range constructor
isn't confused by "N copies of C" when N and C have the same integral type. To do this, it was
testing (100, 65), but that eventually emits truncation warnings from int to char. There's a simple way
to avoid this - passing (static_cast<char>(100), static_cast<char>(65)) also exercises the disambiguation.
(And 100 is representable even when char has a signed range.)
test/std/strings/string.view/string.view.hash/string_view.pass.cpp
Add static_cast<char_type> because `'0' + i` has type int.
test/std/utilities/function.objects/bind/func.bind/func.bind.bind/nested.pass.cpp
What's more horrible than nested bind()? pow() overloads! This operator()(T a, T b) was assuming that
std::pow(a, b) can be returned as T. (In this case, T is int.) However, N4606 26.9.1 [cmath.syn]/2
says that pow(int, int) returns double, so this was truncating double to int.
Adding static_cast<T> silences this.
test/std/utilities/function.objects/unord.hash/integral.pass.cpp
This was iterating `for (int i = 0; i <= 5; ++i)` and constructing `T t(i);` but that's truncating
when T is short. (And super truncating when T is bool.) Adding static_cast<T> silences this.
test/std/utilities/utility/exchange/exchange.pass.cpp
First, this was exchanging 67.2 into an int, but that's inherently truncating.
Changing this to static_cast<short>(67) avoids the truncation while preserving the
"what if T and U are different" test coverage.
Second, this was exchanging {} with the explicit type float into an int, and that's also
inherently truncating. Specifying short is just as good.
test/std/utilities/utility/pairs/pairs.spec/make_pair.pass.cpp
Add static_cast<short>. Note that this affects template argument deduction for make_pair(),
better fulfilling the test's intent. For example, this was saying
`typedef std::pair<int, short> P1; P1 p1 = std::make_pair(3, 4);` but that was asking
make_pair() to return pair<int, int>, which was then being converted to pair<int, short>.
(pair's converting constructors are tested elsewhere.)
Now, std::make_pair(3, static_cast<short>(4)) actually returns pair<int, short>.
(There's still a conversion from pair<nullptr_t, short> to pair<unique_ptr<int>, short>.)
Fixes D27544.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289111 91177308-0d34-0410-b5e6-96231b3b80d8
