argument.  This avoids the argument from being silenced when the argument is
the NULL macro, which is defined in a system header.  This also makes the output
a bit nicer, e.g.:

t.c:8:3: warning: null passed to a callee which requires a non-null argument
  func1(NULL, cp2, i1);
  ^     ~~~~

vs something like:

t.c:8:10: warning: argument is null where non-null is required
  func1(NULL, cp2, i1);
        ^

llvm-svn: 72393

llvm-svn: 72219

llvm-svn: 72158

llvm-svn: 72139

checking when block is envoked. In progress.

llvm-svn: 72039

Fix <rdar://problem/6880975> [format string] Assertion failed: (Arg < NumArgs && "Arg access out of range!").

For format string checking, only check the type of the format
specifier for non-vararg functions.

llvm-svn: 71672

rdar://6880573

llvm-svn: 71636

of the underlying _N builtin, not the the type of the pointee of the
actual type.  This ensures that atomics involving pointers end up
using the correct integer type when they are resolved, avoiding
aborts in codegen.

llvm-svn: 71218

semantic rules that gcc and icc use.  This implements the variadic
and concrete versions as builtins and has sema do the 
disambiguation.  There are probably a bunch of details to finish up
but this seems like a large monotonic step forward :)

llvm-svn: 71212

llvm-svn: 70664

reason for adding these is to error out in CodeGen when trying to generate
them instead of silently emitting a call to a non-existent function.

(Note that it is not valid to lower these to setjmp/longjmp; in addition 
to that lowering being different from the intent, setjmp and longjmp 
require a larger buffer.)

llvm-svn: 70658

This enables one specific class of non-literal format warnings.

llvm-svn: 70368

llvm-svn: 70367

llvm-svn: 70361

expressions that can be of static duration to be returned.
Radar 6786551

llvm-svn: 69331

Teach Sema::SemaBuiltinVAStart() about blocks.

llvm-svn: 69201

llvm-svn: 68982

- Finish up support for converting UTF8->UTF16 to support ObjC @"string" constants.

Remove warning from CheckObjCString.

As the FIXME in the test case indicates, I still have a bug to work out (apparently with \u handling).

llvm-svn: 68245

allow non-literal format strings that are variables that (a) permanently bind to
a string constant and (b) whose string constants are resolvable within the same
translation unit.

llvm-svn: 67404

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

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

llvm-svn: 65642

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

 - <rdar://problem/6094103> sema fails to promote type arguments to __builtin_isgreater (and friends)

llvm-svn: 65059

we used to not account for escapes in strings with
string concat.  Before:

t.m:5:20: warning: field width should have type 'int', but argument has type 'unsigned int'
  printf("\n\n" "\n\n%*d", (unsigned) 1, 1);
                   ^       ~~~~~~~~~~~~

after:

t.m:5:23: warning: field width should have type 'int', but argument has type 'unsigned int'
  printf("\n\n" "\n\n%*d", (unsigned) 1, 1);
                      ^    ~~~~~~~~~~~~

llvm-svn: 64941

escapes in the string for subtoken positioning.  This gives
us working examples like:

t.m:5:16: warning: field width should have type 'int', but argument has type 'unsigned int'
  printf("\n\n%*d", (unsigned) 1, 1);
               ^    ~~~~~~~~~~~~

where before the caret pointed two spaces to the left.

llvm-svn: 64940

We now emit:

t.m:6:15: warning: field width should have type 'int', but argument has type 'unsigned int'
  printf(STR, (unsigned) 1, 1);
         ^    ~~~~~~~~~~~~
t.m:3:18: note: instantiated from:
#define STR "abc%*ddef"
                 ^

which has the correct location in the string literal in the note line.

llvm-svn: 64936

it needs cleaning.

llvm-svn: 64932

and escaped newlines don't throw off the offset computation.

On this testcase:
  printf("abc\
def"
         "%*d", (unsigned) 1, 1);

Before:
t.m:5:5: warning: field width should have type 'int', but argument has type 'unsigned int'
def"
    ^

after:
t.m:6:12: warning: field width should have type 'int', but argument has type 'unsigned int'
         "%*d", (unsigned) 1, 1);
           ^    ~~~~~~~~~~~~

llvm-svn: 64930

First step, handle diagnostics in StringLiteral's that are due to token pasting.

For example, we now handle:
  id str2 = @"foo" 
            "bar"
           @"baz"
           " b\0larg";  // expected-warning {{literal contains NUL character}}

Correctly:

test/SemaObjC/exprs.m:17:15: warning: CFString literal contains NUL character
           " b\0larg";  // expected-warning {{literal contains NUL character}}
           ~~~^~~~~~~

There are several other related issues still to be done.

llvm-svn: 64924

llvm-svn: 64894

about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf, and to translate builtin attributes (from Builtins.def)
into actual attributes on the function declaration.

Use the "printf" format attribute on function declarations to
determine whether we should do format string checking, rather than
looking at an ad hoc list of builtins and "known" function names.

Be a bit more careful about when we consider a function a "builtin" in
C++.

llvm-svn: 64561

we can define builtins such as fprintf, vfprintf, and
__builtin___fprintf_chk. Give a nice error message when we need to
implicitly declare a function like fprintf.

llvm-svn: 64526

printf-like functions, both builtin functions and those in the
C library. The function-call checker now queries this attribute do
determine if we have a printf-like function, rather than scanning
through the list of "known functions IDs". However, there are 5
functions they are not yet "builtins", so the function-call checker
handles them specifically still:

  - fprintf and vfprintf: the builtins mechanism cannot (yet)
    express FILE* arguments, so these can't be encoded.
  - NSLog: the builtins mechanism cannot (yet) express NSString*
    arguments, so this (and NSLogv) can't be encoded.
  - asprintf and vasprintf: these aren't part of the C99 standard
    library, so we really shouldn't be defining them as builtins in
    the general case (and we don't seem to have the machinery to make
    them builtins only on certain targets and depending on whether
    extensions are enabled).

llvm-svn: 64512

etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has two
practical impacts:

  1) When we're supporting the "implicit function declaration" feature
  of C99, these functions will be implicitly declared with the right
  signature rather than as a function returning "int" with no
  prototype. See PR3541 for the reason why this is important (hint:
  GCC always predeclares these functions).
 
  2) If users attempt to redeclare one of these library functions with
  an incompatible signature, we produce a hard error.

This patch does a little bit of work to give reasonable error
messages. For example, when we hit case #1 we complain that we're
implicitly declaring this function with a specific signature, and then
we give a note that asks the user to include the appropriate header
(e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In
case #2, we show the type of the implicit builtin that was incorrectly
declared, so the user can see the problem. We could do better here:
for example, when displaying this latter error message we say
something like:

  'strcpy' was implicitly declared here with type 'char *(char *, char
  const *)'

but we should really print out a fake code line showing the
declaration, like this:

  'strcpy' was implicitly declared here as:

    char *strcpy(char *, char const *)

This would also be good for printing built-in candidates with C++
operator overloading.

The set of C library functions supported by this patch includes all
functions from the C99 specification's <stdlib.h> and <string.h> that
(a) are predefined by GCC and (b) have signatures that could cause
codegen issues if they are treated as functions with no prototype
returning and int. Future work could extend this set of functions to
other C library functions that we know about.

llvm-svn: 64504

- Made allocation of Stmt objects using vanilla new/delete a *compiler
  error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
  operator that takes ASTContext& as an argument.  This ensures that
  all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
  AST nodes use new (ASTContext&).  This is a large patch, but the
  majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
  deallocated using 'delete'.  Instead, one most do
  StmtObject->Destroy(ASTContext&) or do
  ASTContextObject.Deallocate(StmtObject) (the latter not running the
  'Destroy' method).

Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
  ASTContext (previously it used std::vector).  There are a whole
  bunch of other Stmt classes that need to be similarly changed to
  ensure that all memory allocated for ASTs comes from the allocator
  in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h.  This replaces
  the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
  'delete' to free memory instead of a Stmt's 'Destroy' method.

Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!

llvm-svn: 63997

redundant #includes.  Patch by Anders Johnsen!

llvm-svn: 63271

.def file for each library.  This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.

Patch by Anders Johnsen!

llvm-svn: 63111

Fix type of logical negation for C++.

llvm-svn: 62475

Extend string-literal checking for printf() format string to handle conditional
ternary operators where both sides are literals.

This fixes PR 3319: http://llvm.org/bugs/show_bug.cgi?id=3319

llvm-svn: 62117

information for declarations that were referenced via a qualified-id,
e.g., N::C::value. We keep track of the location of the start of the
nested-name-specifier. Note that the difference between
QualifiedDeclRefExpr and DeclRefExpr does have an effect on the
semantics of function calls in two ways:
  1) The use of a qualified-id instead of an unqualified-id suppresses
     argument-dependent lookup
  2) If the name refers to a virtual function, the qualified-id
  version will call the function determined statically while the
  unqualified-id version will call the function determined dynamically
  (by looking up the appropriate function in the vtable).

Neither of these features is implemented yet, but we do print out
qualified names for QualifiedDeclRefExprs as part of the AST printing.

llvm-svn: 61789

llvm-svn: 61055