llvm-svn: 65777

llvm-svn: 65759

"This patch uses the new ObjCImplDecl class to merge  Sema::ImplMethodsVsClassMethods and Sema::ImplCategoryMethodsVsIntfMethods methods.
And now, when clang check a class implementation to find unimplemented methods, it also checks all methods from the class extensions (unnamed categories).

There is also a test case to check this warning.

This patch contains also a minor update for ObjCImplDecl . getNameAsCString and getNameAsString now returns an empty string instead of crashing for unnamed categories."

Patch by Jean-Daniel Dupas!

llvm-svn: 65744

llvm-svn: 65737

Fix invalid VLAs/VMs in Sema::ActOnVariableDeclarator, so that the variable will have the right type by the time the initializer is checked. This ensures that code like

int a[(int)(1.0 / 1.0) = { 1 } will work.

Eli, please review.
 

llvm-svn: 65725

llvm-svn: 65718

notice because it was a negative test with a fix suggested by
Jean-Daniel Dupas.  Convert the test from a negative to a positive
test to catch stuff like this.

llvm-svn: 65708

llvm-svn: 65695

- 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

llvm-svn: 65680

As far as I know, this catches all cases of jumping into the scope of a 
variable with a variably modified type (excluding statement 
expressions) in C.  This is missing some stuff we probably want to check
(other kinds of variably modified declarations, statement expressions, 
indirect gotos/addresses of labels in a scope, ObjC @try/@finally, cleanup 
attribute), the diagnostics aren't very good, and it's not particularly 
efficient, but it's a decent start.

This patch is a slightly modified version of the patch I attached to
PR3259, and it fixes that bug.  I was sort of planning on improving 
it, but I think it's okay as-is, especially since it looks like CodeGen 
doesn't have any use for this sort of data structure.  The only 
significant change I can think of from the version I attached to PR3259 
is that this version skips running the checking code when a function 
doesn't contain any labels.

This patch doesn't cover case statements, which also need similar 
checking; I'm not sure how we should deal with that. Extending the goto 
checking to also check case statements wouldn't be too hard; it's just a 
matter of keeping track of the scope of the closest switch and checking that
the scope of every case is the same as the scope of the switch.  That said, 
it would likely be a performance hit to run this check on every 
function (it's an extra pass over the entire function), so we probably want
some other solution.

llvm-svn: 65678

llvm-svn: 65671

llvm-svn: 65669

llvm-svn: 65668

array types. Semantic checking for the construction of these types has
been factored out of GetTypeForDeclarator and into separate
subroutines (BuildPointerType, BuildReferenceType,
BuildArrayType). We'll be doing the same thing for all other types
(and declarations and expressions).

As part of this, moved the type-instantiation functions into a class
in an anonymous namespace. 

llvm-svn: 65663

llvm-svn: 65656

llvm-svn: 65653

llvm-svn: 65652

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

stubs for those types we don't yet know how to instantiate (everything
that isn't a template parameter!).

We now instantiate default arguments for template type parameters when
needed. This will be our testbed while I fill out the remaining
type-instantiation logic.

llvm-svn: 65649

in C89 mode.  This makes it enabled by default instead of only enabled with
-pedantic.  Clang defaults to c99 mode, so people will see this more often
than with GCC, but they can always use -std=c89 if they really want c89.

llvm-svn: 65647

set HasVAListArg to true when 'Y' is 0 (i.e., ignore the data arguments).

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

llvm-svn: 65642

llvm-svn: 65641

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

strict constant initializer checking.

llvm-svn: 65612

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: 65589

initialization of wchar_t arrays with wide strings, and generalizes
wchar_size.c to work on all targets.

llvm-svn: 65586

Unfortunately this doesn't work yet because wchar_t is completely
broken in C.

llvm-svn: 65585

llvm-svn: 65582

nicely sugared type that shows how the user wrote the actual
specialization. This sugared type won't actually show up until we
start doing instantiations.

llvm-svn: 65577

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

 - No functionality change.

llvm-svn: 65563

Fix <rdar://problem/6574319> clang issues error on 'readonly' property with a defaul setter attribute.

Needed to make isPropertyReadonly() non-const (for this fix to compile). I imagine there's a way to retain the const-ness, however I have more important fish to fry.

llvm-svn: 65562

This was a fairly recent regression.

llvm-svn: 65547

The code for looking up local/private method in Sema::ActOnInstanceMessage() was not handling categories properly. Sema::ActOnClassMessage() didn't have this bug.
Created a helper with the correct logic and changed both methods to use it.

llvm-svn: 65532

llvm-svn: 65529

anymore.  If we want to reuse bits and pieces to add strict checking for 
constant initializers, we can dig them out of SVN history; the existing 
code won't be useful as-is.

llvm-svn: 65502

variable declarations where applicable.  Also, a few fixes to 
TryToFixInvalidVariablyModifiedType for issues that this exposed.

llvm-svn: 65500

decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.

llvm-svn: 65478