| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 65489
|
| |
|
|
|
|
|
|
|
|
|
|
| |
specializations. In particular:
- Make sure class template specializations have a "template<>"
header, and complain if they don't.
- Make sure class template specializations are declared/defined
within a valid context. (e.g., you can't declare a specialization
std::vector<MyType> in the global namespace).
llvm-svn: 65476
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
llvm-svn: 65467
|
| |
|
|
|
|
|
|
|
|
| |
only from a function definition (that does not have a prototype) are
only used to determine the compatible with other declarations of that
same function. In particular, when referencing the function we pretend
as if it does not have a prototype. Implement this behavior, which
fixes PR3626.
llvm-svn: 65460
|
| |
|
|
|
|
|
| |
The big difference here is that (like string literal) @encode has
array type, not pointer type.
llvm-svn: 65391
|
| |
|
|
|
|
|
| |
lookup to skip over names without linkage. This finishes
<rdar://problem/6127293>.
llvm-svn: 65386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- When we are declaring a function in local scope, we can merge with
a visible declaration from an outer scope if that declaration
refers to an entity with linkage. This behavior now works in C++
and properly ignores entities without linkage.
- Diagnose the use of "static" on a function declaration in local
scope.
- Diagnose the declaration of a static function after a non-static
declaration of the same function.
- Propagate the storage specifier to a function declaration from a
prior declaration (PR3425)
- Don't name-mangle "main"
llvm-svn: 65360
|
| |
|
|
|
|
|
| |
of a pointer to object; This patch does this odd behavior according to
gcc.
llvm-svn: 65334
|
| |
|
|
|
|
| |
Remove support for "Class<P>". Will be making this an error.
llvm-svn: 65332
|
| |
|
|
| |
llvm-svn: 65331
|
| |
|
|
| |
llvm-svn: 65305
|
| |
|
|
|
|
|
|
|
|
| |
<rdar://problem/6497631> Message lookup is sometimes different than gcc's).
- Implement instance/class overloading in ObjCContainerDecl (removing a FIXME). This involved hacking NamedDecl::declarationReplaces(), which took awhile to figure out (didn't realize replace was the default).
- Changed Sema::ActOnInstanceMessage() to remove redundant warnings when dealing with protocols. For now, I've omitted the "protocol" term in the diagnostic. It simplifies the code flow and wan't always 100% accurate (e.g. "Foo<Prot>" looks in the class interface, not just the protocol).
- Changed several test cases to jive with the above changes.
llvm-svn: 65292
|
| |
|
|
|
|
|
| |
true a local pointer to objective-c object in generating
write barriers.
llvm-svn: 65290
|
| |
|
|
|
|
| |
someone would reasonably expect Evaluate to handle for C/ObjC.
llvm-svn: 65284
|
| |
|
|
|
|
|
|
| |
I know, these follow the exact same rules as pointers, so I just made
them use the same codepath. Someone more familiar with ObjC should
double-check this, though.
llvm-svn: 65261
|
| |
|
|
|
|
| |
partially done in r65258.)
llvm-svn: 65260
|
| |
|
|
|
|
|
|
|
| |
PR3254 and part of PR3433.
The isICE changes are necessary to keep the computed results
consistent with Evaluate.
llvm-svn: 65258
|
| |
|
|
| |
llvm-svn: 65255
|
| |
|
|
|
|
| |
This is necessary 'plumbing' to fix <rdar://problem/6497631> Message lookup is sometimes different than gcc's.
llvm-svn: 65248
|
| |
|
|
|
|
|
|
| |
Found while researching <rdar://problem/6497631> Message lookup is sometimes different than gcc's.
Will never be seen in user code. Needed to pass dejagnu testsuite.
llvm-svn: 65244
|
| |
|
|
| |
llvm-svn: 65235
|
| |
|
|
|
|
|
| |
expr; hilarity ensued.
- PR3640.
llvm-svn: 65234
|
| |
|
|
|
|
| |
Should clang have a config.h or should we use the config.h of llvm or using the preprocessor is OK? I did a quick fix here, but having a guideline on how to handle non portable function would be great (or ask ted to stop breaking the windows build :)).
llvm-svn: 65233
|
| |
|
|
|
|
|
|
|
|
| |
Move two key ObjC typechecks from Sema::CheckPointerTypesForAssignment() to ASTContext::mergeTypes().
This allows us to take advantage of the recursion in ASTContext::mergeTypes(), removing some bogus warnings.
This test case I've added includes an example where we still warn (and GCC doesn't). Need to talk with folks and decide what to do. At this point, the major bogosities should be fixed.
llvm-svn: 65231
|
| |
|
|
|
|
|
|
|
| |
with new/delete. With disable-free, this reduces the number of 4/8 byte
mallocs from 4793/1541 to 865/456 and also drops other sizes as well.
This is a very small perf win, nothing major.
llvm-svn: 65171
|
| |
|
|
|
|
|
|
| |
ObjCList,
but don't start using it yet. Renamed some methods to be more consistent.
llvm-svn: 65168
|
| |
|
|
| |
llvm-svn: 65166
|
| |
|
|
|
|
| |
before the dtor.
llvm-svn: 65156
|
| |
|
|
|
|
| |
and other non-semantic changes.
llvm-svn: 65155
|
| |
|
|
| |
llvm-svn: 65151
|
| |
|
|
|
|
| |
it from being leaked, among other things.
llvm-svn: 65150
|
| |
|
|
|
|
| |
interfaces more consistently.
llvm-svn: 65138
|
| |
|
|
|
|
| |
- PR3463 (again).
llvm-svn: 65133
|
| |
|
|
| |
llvm-svn: 65132
|
| |
|
|
| |
llvm-svn: 65131
|
| |
|
|
| |
llvm-svn: 65129
|
| |
|
|
| |
llvm-svn: 65127
|
| |
|
|
|
|
| |
ObjCList.
llvm-svn: 65114
|
| |
|
|
| |
llvm-svn: 65113
|
| |
|
|
| |
llvm-svn: 65112
|
| |
|
|
| |
llvm-svn: 65111
|
| |
|
|
|
|
| |
isn't getting used by Sema or CodeGen at the moment...)
llvm-svn: 65107
|
| |
|
|
| |
llvm-svn: 65105
|
| |
|
|
|
|
|
|
|
|
| |
exactly one decl with a specific name in a specific context. This
avoids a bunch of malloc traffic and shrinks StoredDeclsMap to hold
one pointer instead of 3 words (for a std::vector).
This speeds up -fsyntax-only on cocoa.h with PTH by ~7.3%.
llvm-svn: 65103
|
| |
|
|
|
|
| |
from the testsuite.
llvm-svn: 65098
|
| |
|
|
|
|
|
|
| |
where there is exactly one existing declaration. This is common.
this speeds up clang about 3% on cocoa.h for me 0.165 -> 0.160s
llvm-svn: 65096
|
| |
|
|
| |
llvm-svn: 65095
|
| |
|
|
| |
llvm-svn: 65094
|
| |
|
|
|
|
| |
attribute.
llvm-svn: 65078
|
| |
|
|
| |
llvm-svn: 65077
|