| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
TreeTransform, since we were getting an empty source range where we
shouldn't. Sadly, the test case is Boost.Proto, and isn't worth
reducing.
llvm-svn: 113446
|
| |
|
|
|
|
|
|
| |
typeid expressions:
- make sure we have a proper source location for the closing ')'
- cache the declaration of std::type_info once we've found it
llvm-svn: 113441
|
| |
|
|
|
|
| |
pointer type, actually provide a usable block literal expression.
llvm-svn: 113431
|
| |
|
|
| |
llvm-svn: 113416
|
| |
|
|
|
|
|
|
| |
function-style cast. Previously, we had a (redundant, incorrect)
semantic-checking path for non-class types, which allowed
value-initialization of a reference type and then crashed.
llvm-svn: 113415
|
| |
|
|
|
|
|
| |
use of 'struct objc_object*' for 'is' (and others)
in clang.
llvm-svn: 113414
|
| |
|
|
| |
llvm-svn: 113412
|
| |
|
|
|
|
| |
Radar 8400356.
llvm-svn: 113397
|
| |
|
|
| |
llvm-svn: 113356
|
| |
|
|
| |
llvm-svn: 113354
|
| |
|
|
|
|
| |
have a direct initializer. Fixes PR8095.
llvm-svn: 113344
|
| |
|
|
|
|
| |
Fixes PR8110, and thus PR8109, PR8097, and parts of PR8101, PR8105 and PR8107. Only a few traits have tests for incomplete arrays, since I'm not yet clear what the result for them should be; Howards wants to file a DR to change the standard.
llvm-svn: 113326
|
| |
|
|
| |
llvm-svn: 113324
|
| |
|
|
|
|
|
|
| |
CXXTemporaryObjectExpr, CXXScalarValueInitExpr, and
CXXUnresolvedConstructExpr, getting rid of a bunch of FIXMEs in the
process.
llvm-svn: 113319
|
| |
|
|
|
|
| |
the TypeSourceInfo for the allocated type. Fixes PR7501.
llvm-svn: 113291
|
| |
|
|
|
|
| |
instead of asserting in IRGen. Fixes radar 8390459.
llvm-svn: 113253
|
| |
|
|
|
|
|
| |
inline" function outside of GNU89 mode. Fixes
<rdar://problem/6880464>.
llvm-svn: 113204
|
| |
|
|
| |
llvm-svn: 113124
|
| |
|
|
| |
llvm-svn: 113076
|
| |
|
|
| |
llvm-svn: 113074
|
| |
|
|
|
|
| |
kinds. How shameful that this code was duplicated!
llvm-svn: 113033
|
| |
|
|
| |
llvm-svn: 113019
|
| |
|
|
| |
llvm-svn: 113018
|
| |
|
|
|
|
| |
but this makes them work even as an extension in C++98. This resolves PR8077.
llvm-svn: 113011
|
| |
|
|
| |
llvm-svn: 112968
|
| |
|
|
|
|
|
|
|
|
| |
restrictions. The note's not really on the right place given its wording,
but putting a second note on the call site (or muddying the wording) doesn't
appeal.
There are corner cases where this can be wrong, but I'm not concerned.
llvm-svn: 112950
|
| |
|
|
|
|
|
|
|
| |
should probably be removed if it has no purpose, but I just #if'd it out
in case it's usefulIdempotentOperationChecker::isTruncationExtensionAssignment
should probably be removed if it has no purpose, but I just #if'd it out
in case it's useful
llvm-svn: 112949
|
| |
|
|
| |
llvm-svn: 112945
|
| |
|
|
|
|
|
| |
"__attribute((pascal))" or "__pascal" (and "_pascal" under
-fborland-extensions). Support still needs to be added to llvm.
llvm-svn: 112939
|
| |
|
|
| |
llvm-svn: 112933
|
| |
|
|
| |
llvm-svn: 112927
|
| |
|
|
|
|
|
|
|
| |
type" warning.
The rationale behind this is that it is normal for callback functions to have a non-void return type
and it should still be possible to mark them noreturn. (JavaScriptCore is a good example of this).
llvm-svn: 112918
|
| |
|
|
|
|
| |
well-intentioned but completely unused code.
llvm-svn: 112868
|
| |
|
|
|
|
| |
themselves are references. (Fixes PR 7999; fix by Chandler Carruth).
llvm-svn: 112792
|
| |
|
|
| |
llvm-svn: 112715
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ReferencedProtocols and AllReferencedProtocols. ReferencedProtocols
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
llvm-svn: 112691
|
| |
|
|
|
|
| |
doesn't fit. Instead, special-case the few places where transparent contexts have the desired behavior for inline namespaces. Fixes a redeclaration issue in inline namespaces.
llvm-svn: 112637
|
| |
|
|
|
|
|
| |
This is also pr7726 and wip. No change in functionality
at this time.
llvm-svn: 112612
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
libclang. This includes:
- Cursor kind for function templates, with visitation logic
- Cursor kinds for template parameters, with visitation logic
- Visitation logic for template specialization types, qualified type
locations
- USR generation for function templates, template specialization
types, template parameter types.
Also happens to fix PR7804, which I tripped across while testing.
llvm-svn: 112604
|
| |
|
|
|
|
| |
terrible, FIXME left to do a proper job of diagnosing this.
llvm-svn: 112581
|
| |
|
|
|
|
|
|
| |
declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.
llvm-svn: 112579
|
| |
|
|
|
|
| |
testcase for inline namespace fun.
llvm-svn: 112565
|
| |
|
|
| |
llvm-svn: 112564
|
| |
|
|
|
|
| |
semantics slightly. No functionality change in the absence of inline namespaces. Also, change a few places where inline namespaces actually make a difference to be prepared for them.
llvm-svn: 112563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiating the parameters. In a perfect world, this wouldn't
matter, and compilers are free to instantiate in any order they
want. However, every other compiler seems to instantiate the return
type first, and some code (in this case, Boost.Polygon) depends on
this and SFINAE to avoid instantiating something that shouldn't be
instantiated.
We could fight this battle, and insist that Clang is allowed to do
what it does, but it's not beneficial: it's more predictable to
instantiate this way, in source order. When we implement
late-specified return types, we'll need to instantiate the return type
last when it was late-specified, hence the FIXME.
We now compile Boost.Polygon properly.
llvm-svn: 112561
|
| |
|
|
| |
llvm-svn: 112552
|
| |
|
|
|
|
|
|
|
|
|
|
| |
of that parameter, reduce the level by the number of active template
argument lists rather than by 1. The number of active template
argument lists is only > 1 when we have a class template partial
specialization of a member template of a class template that itself is
a member template of another class template.
... and Boost.MSM does this. Fixes PR7669.
llvm-svn: 112551
|
| |
|
|
| |
llvm-svn: 112541
|
| |
|
|
|
|
|
|
|
|
| |
namely when the friend function prototype is already used
at the point of the template definition that is supposed
to inject the friend function. Testcase verifies four
scenarios.
I would like receive some code review for this.
llvm-svn: 112524
|
| |
|
|
|
|
|
|
|
| |
deduction where the parameter is a function reference, function
pointer, or member function pointer and the argument is an overloaded
function. Fixes <rdar://problem/8360106>, a template argument
deduction issue found by Boost.Filesystem.
llvm-svn: 112523
|