| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
this. Thanks to Peter Klotz for calling my attention to this.
llvm-svn: 333467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from Arthur O'Dwyer.
In the TS, `uses_allocator` construction for `pair` tried to use an allocator
type of `memory_resource*`, which is incorrect because `memory_resource*` is
not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the
allocator type instead.
https://wg21.link/lwg2969
(D47090 included this in `<memory_resource>`; at Eric's request, I've split
this out into its own patch applied to the existing
`<experimental/memory_resource>` instead.)
Reviewed as https://reviews.llvm.org/D47109
llvm-svn: 333384
|
|
|
|
|
|
| |
template deduction guides - specifically for copy-ctors
llvm-svn: 333381
|
|
|
|
|
|
| |
deduces the wrong type.
llvm-svn: 333376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
llvm-svn: 333351
|
|
|
|
|
|
| |
r333325 from D47225 added warning checks, and the test was written to be C++11 correct by using ATOMIC_VAR_INIT (note that the committee fixed that recently...). It seems like GCC can't handle ATOMIC_VAR_INIT well because it generates 'type 'std::atomic<int>' cannot be initialized with an initializer list' on bot libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03. Drop the ATOMIC_VAR_INITs since they weren't required to test the diagnostics.
llvm-svn: 333327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
llvm-svn: 333325
|
|
|
|
|
|
| |
It seems GCC and clang disagree. Talked to mclow on IRC, disabling for now.
llvm-svn: 333317
|
|
|
|
|
|
| |
No matching constructor
llvm-svn: 333315
|
|
|
|
| |
llvm-svn: 333308
|
|
|
|
| |
llvm-svn: 333252
|
|
|
|
| |
llvm-svn: 333251
|
|
|
|
|
|
|
|
| |
if the compiler is not clang.
gcc doesn't allow using __fp16 on non-ARM targets.
llvm-svn: 333108
|
|
|
|
|
|
|
|
| |
floating-point types.
rdar://problem/40377353
llvm-svn: 333103
|
|
|
|
| |
llvm-svn: 333050
|
|
|
|
| |
llvm-svn: 333011
|
|
|
|
| |
llvm-svn: 332931
|
|
|
|
| |
llvm-svn: 332927
|
|
|
|
| |
llvm-svn: 332901
|
|
|
|
| |
llvm-svn: 332818
|
|
|
|
| |
llvm-svn: 332811
|
|
|
|
|
|
| |
int/long are the same size
llvm-svn: 332797
|
|
|
|
| |
llvm-svn: 332785
|
|
|
|
| |
llvm-svn: 332779
|
|
|
|
|
|
| |
https://reviews.llvm.org/D46964
llvm-svn: 332768
|
|
|
|
|
|
| |
test/std/numerics/rand/rand.eng/rand.eng.lcong/default.pass.cpp
llvm-svn: 332571
|
|
|
|
| |
llvm-svn: 332567
|
|
|
|
|
|
| |
The test is passing with apple-clang-9.1. rdar://problem/40222003
llvm-svn: 332282
|
|
|
|
| |
llvm-svn: 332159
|
|
|
|
| |
llvm-svn: 332066
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Checking for complete types is really rather tricky when you consider
the amount of specializations required to check a function type. This
specifically caused PR37407 where we incorrectly diagnosed
noexcept function types as incomplete (but there were plenty of other
cases that would cause this).
This patch removes the complete type checking for now. I'm going
to look into adding a clang builtin to correctly do this for us.
llvm-svn: 332040
|
|
|
|
|
|
|
| |
It reverts commit r331379 because turned out `__ALLOW_STDC_ATOMICS_IN_CXX__`
doesn't work well in practice.
llvm-svn: 331818
|
|
|
|
|
|
| |
Strip trailing whitespace and untabify.
llvm-svn: 331576
|
|
|
|
|
|
|
|
| |
warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data
Requesting post-commit review.
llvm-svn: 331575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331379
|
|
|
|
|
|
|
|
|
|
|
| |
When using an old version of glibc, a ::isinf(double) and ::isnan(double)
function is provided, rather than just the macro required by C and C++.
Displace this function using _LIBCPP_PREFERRED_OVERLOAD where possible.
The only remaining case where we should get the wrong return type is now
glibc + libc++ + a non-clang compiler.
llvm-svn: 331241
|
|
|
|
|
|
|
|
|
|
|
| |
seekoff.pass.cpp:
libc++'s tests are asserting things about the buffer passed to pubsetbuf. [filebuf.virtuals]/12 says that what the filebuf does with the buffer you give it is completely implementation defined. The MSVC++ implementation takes that buffer and hands it off to the CRT (by calling ::setvbuf) and the CRT doesn't necessarily follow the pattern this test wants.
This change simply makes asserts against the buffer's contents use LIBCPP_ASSERT instead of assert.
pbackfail.pass.cpp:
libc++'s tests are asserting about what characters will and will not be available in the putback area. [filebuf.virtuals]/9 says "The function can alter the number of putback positions available as a result of any call." This change LIBCPP_ASSERTS libc++'s behavior, but checks invariants of the putback area independently.
llvm-svn: 330999
|
|
|
|
|
|
| |
ostreambuf_iterator::failed. Fixes PR#37245. Thanks to Billy O'Neill for the bug report.
llvm-svn: 330955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Be defensive against a reentrant std::function::operator=(nullptr_t), in case
the held function object has a non-trivial destructor. Destroying the function
object in-place can lead to the destructor being called twice.
Patch by Duncan P. N. Exon Smith. C++03 support by Volodymyr Sapsai.
rdar://problem/32836603
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D34331
llvm-svn: 330885
|
|
|
|
| |
llvm-svn: 330838
|
|
|
|
|
|
| |
Ricky Zhou for the report and test case.
llvm-svn: 330828
|
|
|
|
|
|
|
|
|
|
| |
directory" from ios_base::failure tests
These io_error asserts that std::errc::is_a_directory has message "Is a directory". On MSVC++ it reports "is a directory" (with a lowercase I). That doesn't matter for the ios_failure component being tested, so just implement in terms of system_category().message().
Reviewed as https://reviews.llvm.org/D45715
llvm-svn: 330791
|
|
|
|
|
|
|
|
|
|
|
|
| |
on P0214R7."
There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
narrowing conversion SFINAE test (see GCC PR63723).
llvm-svn: 330655
|
|
|
|
|
|
|
|
| |
This reverts commit r330627.
This causes several bots to freak out.
llvm-svn: 330636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The patch includes all declarations, and also implements the following features:
* ABI.
* narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast.
Reviewers: mclow.lists, EricWF
Subscribers: lichray, sanjoy, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D41148
llvm-svn: 330627
|
|
|
|
|
|
| |
Fixes D45595.
llvm-svn: 329979
|
|
|
|
|
|
| |
test/std almost always uses spaces; now it is entirely tab-free.
llvm-svn: 329978
|
|
|
|
|
|
| |
Also TEST_COMPILER_CLANG in one place. (More could be changed.)
llvm-svn: 329977
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test code triggers the MSVC warning:
"unary minus operator applied to unsigned type, result still unsigned"
Although it would be possible to change the test code to avoid
this warning, I have chosen to simply silence it.
Fixes D45594.
llvm-svn: 329976
|
|
|
|
|
|
|
|
| |
MSVC's STL has marked to_bytes/from_bytes as nodiscard.
Fixes D45595.
llvm-svn: 329975
|