|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3 |
|
| #
c90dac27 |
| 31-Jan-2021 |
Justin Lebar <justin.lebar@gmail.com> |
[clang] Print 32 candidates on the first failure, with -fshow-overloads=best.
Previously, -fshow-overloads=best always showed 4 candidates. The
problem is, when this isn't enough, you're kind of up
[clang] Print 32 candidates on the first failure, with -fshow-overloads=best.
Previously, -fshow-overloads=best always showed 4 candidates. The
problem is, when this isn't enough, you're kind of up a creek; the only
option available is to recompile with different flags. This can be
quite expensive!
With this change, we try to strike a compromise. The *first* error with
more than 4 candidates will show up to 32 candidates. All further
errors continue to show only 4 candidates.
The hope is that this way, users will have *some chance* of making
forward progress, without facing unbounded amounts of error spam.
Differential Revision: https://reviews.llvm.org/D95754
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
70f59b5b |
| 24-Oct-2019 |
Richard Smith <richard@metafoo.co.uk> |
When diagnosing an ambiguity, only note the candidates that contribute
to the ambiguity, rather than noting all viable candidates.
|
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1 |
|
| #
d74ebe22 |
| 11-Apr-2018 |
Jan Korous <jkorous@apple.com> |
[Sema] Fix built-in decrement operator overload resolution
C++ [over.built] p4:
"For every pair (T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exi
[Sema] Fix built-in decrement operator overload resolution
C++ [over.built] p4:
"For every pair (T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exist candidate operator functions of the form
VQ T& operator--(VQ T&);
T operator--(VQ T&, int);
"
The bool type is in position LastPromotedIntegralType in BuiltinOperatorOverloadBuilder::getArithmeticType::ArithmeticTypes, but addPlusPlusMinusMinusArithmeticOverloads() was expecting it at position 0.
Differential Revision: https://reviews.llvm.org/D44988
rdar://problem/34255516
llvm-svn: 329804
show more ...
|
|
Revision tags: llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
bb1ea2d6 |
| 09-May-2016 |
Nemanja Ivanovic <nemanja.i.ibm@gmail.com> |
Enable support for __float128 in Clang and enable it on pertinent platforms
This patch corresponds to reviews:
http://reviews.llvm.org/D15120
http://reviews.llvm.org/D19125
It adds support for the
Enable support for __float128 in Clang and enable it on pertinent platforms
This patch corresponds to reviews:
http://reviews.llvm.org/D15120
http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
show more ...
|
| #
d7d45bf8 |
| 15-Apr-2016 |
Nemanja Ivanovic <nemanja.i.ibm@gmail.com> |
Revert 266186 as it breaks anything that includes type_traits on some platforms
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms
Revert 266186 as it breaks anything that includes type_traits on some platforms
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
show more ...
|
| #
50f29e06 |
| 13-Apr-2016 |
Nemanja Ivanovic <nemanja.i.ibm@gmail.com> |
Enable support for __float128 in Clang
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This
Enable support for __float128 in Clang
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
show more ...
|
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2 |
|
| #
e7cbb3ed |
| 17-Nov-2015 |
Charles Li <charles_li@playstation.sony.com> |
[Lit Test] Updated 34 Lit tests to be C++11 compatible.
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
Revision tags: llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1, llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1, llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1, llvmorg-3.2.0 |
|
| #
3f2f7926 |
| 07-Dec-2012 |
NAKAMURA Takumi <geek4civic@gmail.com> |
clang/test: Remove "REQUIRES:LP64" in two tests. Each of them have explicit triple.
llvm-svn: 169587
|
|
Revision tags: llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2 |
|
| #
e6a56db2 |
| 29-Nov-2012 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Reject uses of __int128 on platforms that don't support it. Also move the ugly
'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be
properly cleaned up.
llvm-svn: 168856
|
|
Revision tags: llvmorg-3.2.0-rc1 |
|
| #
fcd16e36 |
| 12-Sep-2012 |
NAKAMURA Takumi <geek4civic@gmail.com> |
clang/test: [PR8833] Introduce the feature "LP64" to suppress LLP64-incompatible tests.
I think some of them could be rewritten to fit also LLP64.
llvm-svn: 163699
|
| #
521ecc1f |
| 10-Jun-2012 |
Richard Smith <richard-llvm@metafoo.co.uk> |
PR12964: __int128 and unsigned __int128 are promoted integral types, be sure to
consider them when enumerating builtin operator candidates.
llvm-svn: 158293
|
| #
5bee2588 |
| 04-Jun-2012 |
Douglas Gregor <dgregor@apple.com> |
When adding built-in operator candidates for overload resolution
involving 'restrict', place restrict on the pointer type rather than
on the pointee type. Also make sure that we gather restrict from
When adding built-in operator candidates for overload resolution
involving 'restrict', place restrict on the pointer type rather than
on the pointee type. Also make sure that we gather restrict from the
pointer type. Fixes PR12854 and the major part of PR11093.
llvm-svn: 157910
show more ...
|
|
Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1, llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2, llvmorg-3.0.0-rc1, llvmorg-2.9.0, llvmorg-2.9.0-rc3, llvmorg-2.9.0-rc2, llvmorg-2.9.0-rc1 |
|
| #
66990031 |
| 05-Jan-2011 |
Douglas Gregor <dgregor@apple.com> |
Many of the built-in operator candidates introduced into overload
resolution require that the pointed-to type be an object type, but we
weren't filtering out non-object types. Do so, fixing PR7851.
Many of the built-in operator candidates introduced into overload
resolution require that the pointed-to type be an object type, but we
weren't filtering out non-object types. Do so, fixing PR7851.
llvm-svn: 122853
show more ...
|
| #
b37c9af7 |
| 03-Nov-2010 |
Douglas Gregor <dgregor@apple.com> |
When producing overload candidates for binary built-in operators, keep
the sets of available conversions for the first and second arguments
separate. This is apparently the indent of C++ [over.built]
When producing overload candidates for binary built-in operators, keep
the sets of available conversions for the first and second arguments
separate. This is apparently the indent of C++ [over.built], and
reduces the number of overload candidates generated, eliminating some
ambiguities. Fixes PR8477.
llvm-svn: 118178
show more ...
|
|
Revision tags: llvmorg-2.8.0, llvmorg-2.8.0-rc3, llvmorg-2.8.0-rc2, llvmorg-2.8.0-rc1, llvmorg-2.8.0-rc0 |
|
| #
2b99c6fc |
| 11-Jun-2010 |
Jeffrey Yasskin <jyasskin@google.com> |
Add an option -fshow-overloads=best|all to limit the number of overload
candidates printed. We default to 'all'. At the moment, 'best' prints only
the first 4 overloads, but we'll improve that over
Add an option -fshow-overloads=best|all to limit the number of overload
candidates printed. We default to 'all'. At the moment, 'best' prints only
the first 4 overloads, but we'll improve that over time.
llvm-svn: 105815
show more ...
|
| #
ce21919b |
| 08-Jun-2010 |
Douglas Gregor <dgregor@apple.com> |
A built-in overload candidate is consider a non-template function when
determining whether one overload candidate is better than
another. Fixes PR7319.
llvm-svn: 105642
|
|
Revision tags: llvmorg-2.7.0 |
|
| #
e1ac8d17 |
| 13-Jan-2010 |
John McCall <rjmccall@apple.com> |
Improve the reporting of non-viable overload candidates by noting the reason
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements sh
Improve the reporting of non-viable overload candidates by noting the reason
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
llvm-svn: 93277
show more ...
|
| #
fd0b2f8f |
| 06-Jan-2010 |
John McCall <rjmccall@apple.com> |
Improve the diagnostics used to report implicitly-generated class members
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
llv
Improve the diagnostics used to report implicitly-generated class members
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
llvm-svn: 92832
show more ...
|
| #
8fbe78f6 |
| 15-Dec-2009 |
Daniel Dunbar <daniel@zuster.org> |
Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead o
Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
show more ...
|
| #
461a2c06 |
| 14-Nov-2009 |
Anders Carlsson <andersca@mac.com> |
Always build a builtin operator expression for the __extension__ unary operator.
llvm-svn: 88811
|
| #
facfdd4d |
| 09-Nov-2009 |
Fariborz Jahanian <fjahanian@apple.com> |
For array pointee type, get its cvr qualifier from
its element type. Fixes pr5432.
llvm-svn: 86587
|
|
Revision tags: llvmorg-2.6.0 |
|
| #
b8440a76 |
| 21-Oct-2009 |
Douglas Gregor <dgregor@apple.com> |
Don't generate pointer types for void or base classes when finding
conversion types for builtin overloaded operator candidates; I misread
this section in the standard the first time around.
llvm-svn
Don't generate pointer types for void or base classes when finding
conversion types for builtin overloaded operator candidates; I misread
this section in the standard the first time around.
llvm-svn: 84788
show more ...
|
| #
66950a32 |
| 30-Sep-2009 |
Douglas Gregor <dgregor@apple.com> |
When overload resolution fails for an overloaded operator, show the
overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
When overload resolution fails for an overloaded operator, show the
overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
diagnostic, then print the candidates following that diagnostic.
One side advantage of this approach is that we can perform more validation
of C++'s operator overloading with built-in candidates vs. the
semantic analysis for those built-in operators: when there are no
viable candidates, we know to expect an error from the built-in
operator handling code. Otherwise, we are not modeling the built-in
semantics properly within operator overloading. This is checked as:
assert(Result.isInvalid() &&
"C++ binary operator overloading is missing
candidates!");
if (Result.isInvalid())
PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false);
The assert() catches cases where we're wrong in a +Asserts build. The
"if" makes sure that, if this happens in a production clang
(-Asserts), we still build the proper built-in operator and continue
on our merry way. This is effectively what happened before this
change, but we've added the assert() to catch more flies.
llvm-svn: 83175
show more ...
|
| #
b00b10eb |
| 24-Aug-2009 |
Douglas Gregor <dgregor@apple.com> |
Implement support for equality comparisons (!=, ==) of member
pointers, by extending the "composite pointer type" logic to include
member pointer types.
Introduce test cases for member pointer compa
Implement support for equality comparisons (!=, ==) of member
pointers, by extending the "composite pointer type" logic to include
member pointer types.
Introduce test cases for member pointer comparisons, including those
that involve the builtin operator candidates implemented earlier.
llvm-svn: 79925
show more ...
|
| #
027de2ad |
| 21-May-2009 |
Sebastian Redl <sebastian.redl@getdesigned.at> |
Avoid using the built-in type checker for assignment in C++ when classes are involved. Patch by Vyacheslav Kononenko.
llvm-svn: 72212
|