Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality.

llvm-svn: 67029

always, refactored the existing logic to tease apart the parser action
and the semantic analysis shared by the parser and template
instantiation.

llvm-svn: 66987

  - C++ function casts, e.g., T(foo)
  - sizeof(), alignof()

More importantly, this allows us to verify that we're performing
overload resolution during template instantiation, with
argument-dependent lookup and the "cached" results of name lookup from
the template definition.

llvm-svn: 66947

instantiation for binary operators. This change moves most of the
operator-overloading code from the parser action ActOnBinOp to a new,
parser-independent semantic checking routine CreateOverloadedBinOp. 

Of particular importance is the fact that CreateOverloadedBinOp does
*not* perform any name lookup based on the current parsing context (it
doesn't take a Scope*), since it has to be usable during template
instantiation, when there is no scope information. Rather, it takes a
pre-computed set of functions that are visible from the context or via
argument-dependent lookup, and adds to that set any member operators
and built-in operator candidates. The set of functions is computed in
the parser action ActOnBinOp based on the current context (both
operator name lookup and argument-dependent lookup). Within a
template, the set computed by ActOnBinOp is saved within the
type-dependent AST node and is augmented with the results of
argument-dependent name lookup at instantiation time (see
TemplateExprInstantiator::VisitCXXOperatorCallExpr).

Sadly, we can't fully test this yet. I'll follow up with template
instantiation for sizeof so that the real fun can begin.

llvm-svn: 66923

Also changed BlockDecl API to be more consistent (wrt FunctionDecl).

llvm-svn: 66904

This solution is much simpler (and doesn't add any per-scope overhead, which concerned Chris). 

The only downside is the LabelMap is now declared in two places (Sema and BlockSemaInfo). My original fix tried to unify the LabelMap in "Scope" (which would support nested functions in general). In any event, this fixes the bug given the current language definition. If/when we decide to support GCC style nested functions, this will need to be tweaked.

llvm-svn: 66896

Remove ActiveScope (revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).

Will replace with something better today...

llvm-svn: 66893

C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time. 

Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.

Instantiation of these expressions is completely wrong. I'll work on
that next.

llvm-svn: 66851

llvm-svn: 66837

should fix the largest problem in <rdar://problem/6669847>.

llvm-svn: 66741

llvm-svn: 66696

llvm-svn: 66689

template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?

llvm-svn: 66662

llvm-svn: 66659

llvm-svn: 66658

llvm-svn: 66551

This fixes <rdar://problem/6496506> Implement class setter/getter for properties.

llvm-svn: 66465

Rename DiagnoseIncompleteType to RequireCompleteType, and update the documentation to reflect the fact that we can instantiate templates here

llvm-svn: 66421

llvm-svn: 66416

llvm-svn: 66387

warning to only trigger when there is whitespace or something else after the + as
suggested by Eli.

llvm-svn: 66370

difficult to come up with a testcase because the code generation for this
construct is broken.

llvm-svn: 66325

SemaObjC/call-super-2.m:78:29: error: cannot cast 'super' (it isn't an expression)
   return [(Object <Func> *)super instance_func0];
           ~~~~~~~~~~~~~~~~~^

llvm-svn: 66215

Tweak Sema::ActOnMemberReferenceExpr() and Sema::ActOnDeclarationNameExpr() to handle "super." notation for Class methods.

llvm-svn: 66185

c-style functions declared inside objc @implementations.

llvm-svn: 66087

Partial fix for <rdar://problem/6645157> [clang on Xcode; regression]: error: instance variable 'someField' is private.

A recent regression caused by http://llvm.org/viewvc/llvm-project?rev=65912&view=rev.

This commit isn't fully baked. Nevertheless, it should cause Xcode to compile again. Will speak with Fariborz offline.

llvm-svn: 66045

Finish up some fixes related to <rdar://problem/6497631> Message lookup is sometimes different than gcc's.

- Disallow casting 'super'. GCC allows this, however it doesn't make sense (super isn't an expression and the cast won't alter lookup/dispatch).
- Tighten up lookup when messaging 'self'.

llvm-svn: 66033

llvm-svn: 65912

local or global variables in instance/class methods.

llvm-svn: 65879

need them to evaluate redeclarations or call a function that hasn't
already been declared. We now keep a DenseMap of these locally-scoped
declarations so that they are not visible but can be quickly found,
e.g., when we're looking for previous declarations or before we go
ahead and implicitly declare a function that's being called. Fixes
PR3672.

llvm-svn: 65792

llvm-svn: 65718

- Move the 'LabelMap' from Sema to Scope. To avoid layering problems, the second element is now a 'StmtTy *', which makes the LabelMap a bit more verbose to deal with.
- Add 'ActiveScope' to Sema. Managed by ActOnStartOfFunctionDef(), ObjCActOnStartOfMethodDef(), ActOnBlockStmtExpr().
- Changed ActOnLabelStmt(), ActOnGotoStmt(), ActOnAddrLabel(), and ActOnFinishFunctionBody() to use the new ActiveScope.
- Added FIXME to workaround in ActOnFinishFunctionBody() (for dealing with C++ nested functions).  

llvm-svn: 65694

building nested member expressions. This location is used to determine the range
of the entire expression, and the expression itself already has its location
inherited from its Base.

This fixes <rdar://problem/6629829>.

llvm-svn: 65650

normal expression, and change Evaluate and IRGen to evaluate it like a 
normal expression.  This simplifies the code significantly, and fixes 
PR3396.

llvm-svn: 65622

giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types. 

Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved 
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.

As part of this, some types have been renamed:

  TypeOfExpr -> TypeOfExprType
  FunctionTypeProto -> FunctionProtoType
  FunctionTypeNoProto -> FunctionNoProtoType

There shouldn't be any functionality change...

llvm-svn: 65591

llvm-svn: 65582

know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:

  - Insert some new code (a text string) at a particular source
    location
  - Remove the code within a given range
  - Replace the code within a given range with some new code (a text
    string)

Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:

  template<int I> class B { };
  B<1000 >> 2> *b1;

we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:

test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
  B<1000 >> 2> *b1;
         ^
    (        )


Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.

In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.

This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).

llvm-svn: 65570

llvm-svn: 65529

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

Sema::CheckAssignmentConstraints; not really visible, but the right 
thing to do.

llvm-svn: 65428