| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
own subcategory, -Wconstant-conversion, which is on by default.
Tweak the constant folder to give better results in the invalid
case of a negative shift amount.
Implements rdar://problem/6792488
llvm-svn: 118636
|
| |
|
|
| |
llvm-svn: 118635
|
| |
|
|
|
|
| |
// rdar://8632525
llvm-svn: 118634
|
| |
|
|
|
|
| |
conditional operators. Fixes PR7863.
llvm-svn: 118631
|
| |
|
|
|
|
| |
// rdar://8283484
llvm-svn: 118629
|
| |
|
|
| |
llvm-svn: 118626
|
| |
|
|
|
|
| |
being constructed.
llvm-svn: 118625
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
|
| |
|
|
| |
llvm-svn: 118619
|
| |
|
|
|
|
| |
what to use" in the message :)
llvm-svn: 118612
|
| |
|
|
|
|
|
|
| |
to be consistent with all other snippets on this page.
Patch by Jean-Daniel Dupas!
llvm-svn: 118603
|
| |
|
|
|
|
|
|
| |
mangler. Now member functions and pointers thereof have their calling
convention mangled as __thiscall if they have the default CC (even though,
they technically still have the __cdecl CC).
llvm-svn: 118598
|
| |
|
|
| |
llvm-svn: 118514
|
| |
|
|
|
|
|
| |
Set Haiku's UserLabelPrefix to "".
Patch by Paul Davey.
llvm-svn: 118510
|
| |
|
|
|
|
| |
with, e.g., (&f)(a, b, c). Fixes PR8013.
llvm-svn: 118508
|
| |
|
|
| |
llvm-svn: 118500
|
| |
|
|
| |
llvm-svn: 118498
|
| |
|
|
|
|
| |
Fix linux build.
llvm-svn: 118497
|
| |
|
|
|
|
| |
Confirmed on MSVS10.
llvm-svn: 118496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
Take 2: this time, adjusted tests appropriately and used a "simple"
approach to the spelling location.
llvm-svn: 118495
|
| |
|
|
| |
llvm-svn: 118494
|
| |
|
|
| |
llvm-svn: 118493
|
| |
|
|
|
|
|
|
|
|
|
| |
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
llvm-svn: 118492
|
| |
|
|
|
|
| |
a first step towards fixing PR6995.
llvm-svn: 118491
|
| |
|
|
| |
llvm-svn: 118487
|
| |
|
|
| |
llvm-svn: 118485
|
| |
|
|
|
|
|
| |
definitions in its results. The original declarations will be visible
wherever they are declared.
llvm-svn: 118484
|
| |
|
|
| |
llvm-svn: 118483
|
| |
|
|
| |
llvm-svn: 118482
|
| |
|
|
|
|
| |
Wieczorek! Fixes PR8025.
llvm-svn: 118481
|
| |
|
|
| |
llvm-svn: 118480
|
| |
|
|
| |
llvm-svn: 118479
|
| |
|
|
| |
llvm-svn: 118478
|
| |
|
|
| |
llvm-svn: 118476
|
| |
|
|
|
|
| |
has broken a build.
llvm-svn: 118475
|
| |
|
|
| |
llvm-svn: 118474
|
| |
|
|
|
|
| |
<rdar://problem/8642434>.
llvm-svn: 118473
|
| |
|
|
|
|
|
|
| |
'(' and ')'. This can happen
in the case of transparent unions.
llvm-svn: 118472
|
| |
|
|
|
|
| |
Fixes rdar://8644873 & http://llvm.org/PR8567.
llvm-svn: 118468
|
| |
|
|
|
|
|
|
|
|
|
|
| |
there's no return adjustment from the overridden to the overrider doesn't
mean there isn't a return adjustment from the overrider to the final
overrider. This matters if we're emitting a virtual this-adjustment thunk
because the overrider virtually inherits from the class providing the
nearest overridden method. Do the appropriate return adjustment in this case.
Fixes PR7611.
llvm-svn: 118466
|
| |
|
|
|
|
| |
block so that it looks more like the rest of the file. No functional change.
llvm-svn: 118459
|
| |
|
|
|
|
| |
Fixes PR8001.
llvm-svn: 118454
|
| |
|
|
|
|
| |
to avoid a bogus warning. Fixes //rdar: //8632525
llvm-svn: 118451
|
| |
|
|
|
|
|
|
| |
contentful, since the typo was in the method-name...
2) Clarify some comments in RecursiveASTVisitor.
llvm-svn: 118448
|
| |
|
|
|
|
|
|
|
| |
we can blow out the stack due
to deeply nested BinaryOperators. This is done by turning the explicit recursion into being data recursive.
Fixes: <rdar://problem/8289205>
llvm-svn: 118444
|
| |
|
|
|
|
|
|
| |
and we statically can compute a bound on the actual type (e.g.,
because it's a send to the the magic "class" instance method), code
complete as if we were performing a class message send to that class.
llvm-svn: 118443
|
| |
|
|
|
|
|
| |
tweak the documentation for deprecation-with-message. Provide __has_feature
tests for both. rdar://problem/8605692
llvm-svn: 118435
|
| |
|
|
| |
llvm-svn: 118433
|
| |
|
|
|
|
|
|
| |
is complete.
Fixes rdar://8620582 & http://llvm.org/PR7905
llvm-svn: 118428
|
| |
|
|
|
|
| |
inside blocks. Fixes //rdar: //8608293.
llvm-svn: 118425
|