llvm-svn: 65023

llvm-svn: 65021

situation where a tentative decl was emitted *after* the actual
initialization. This occurs in some rare situations with static decls.
 - PR3613.

 - I'm not particularly happy with this fix, but I don't see a simpler
   or more elegant solution yet.

llvm-svn: 65018

llvm-svn: 65013

llvm-svn: 65004

llvm-svn: 64993

llvm-svn: 64985

C*. They're required errors in C++.

llvm-svn: 64964

llvm-svn: 64960

llvm-svn: 64957

(as GCC does), except when we've performed overload resolution and
found an unavailable function: in this case, we actually error.

Merge the checking of unavailable functions with the checking for
deprecated functions. This unifies a bit of code, and makes sure that
we're checking for unavailable functions in the right places. Also,
this check can cause an error. We may, eventually, want an option to
make "unavailable" warnings into errors.

Implement much of the logic needed for C++0x deleted functions, which
are effectively the same as "unavailable" functions (but always cause
an error when referenced). However, we don't have the syntax to
specify deleted functions yet :)

llvm-svn: 64955

This knocks out another 8 gcc/compat/i386 & x86_64 failures.

llvm-svn: 64947

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

llvm-svn: 64929

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

any named parameters, e.g., this is accepted in C:

  void f(...) __attribute__((overloadable));

although this would be rejected:

  void f(...);

To do this, moved the checking of the "ellipsis without any named
arguments" condition from the parser into Sema (where it belongs anyway).

llvm-svn: 64902

to do in this area, since there are other places that reference
FunctionDecls.

Don't allow "overloadable" functions (in C) to be declared without a
prototype.

llvm-svn: 64897

llvm-svn: 64886

compatible, even if they are weird implicit objc pointer types like
Class.

llvm-svn: 64885

question.  Use __builtin_alloca instead, which is guaranteed to mean the right
thing without any includes.

llvm-svn: 64868

llvm-svn: 64867

Add assert to isICE that, on success, result must be the same as
EvaluateAsInt()... this enforces a minimum level of sanity.

llvm-svn: 64865

Update several tests to explicitly use BasicConstraintManager as well as to use RangeConstraintManager with RegionStoreManager.

llvm-svn: 64854

specialization of class templates, e.g.,

  template<typename T> class X;

  template<> class X<int> { /* blah */ };

Each specialization is a different *Decl node (naturally), and can
have different members. We keep track of forward declarations and
definitions as for other class/struct/union types.

This is only the basic framework: we still have to deal with checking
the template headers properly, improving recovery when there are
failures, handling nested name specifiers, etc.

llvm-svn: 64848

llvm-svn: 64837

 - Renamed to getDeclAlignInBytes since most other query functions
   work in bits.

 - Fun to track down as isIntegerConstantExpr was getting it right,
   but Evaluate() was getting it wrong. Maybe we should assert they
   compute the same thing when they succeed?

llvm-svn: 64828

llvm-svn: 64799

Enhance tests to exercise more combinations of using the RangeConstraintManager with the RegionStoreManager.

llvm-svn: 64788

llvm-svn: 64781

IRgen no longer relies on isConstantInitializer, instead we just try
to emit the constant. If that fails then in C we emit an error
unsupported (this occurs when Sema accepted something that it doesn't
know how to fold, and IRgen doesn't know how to emit) and in C++ we
emit a guarded initializer.

This ends up handling a few more cases, because IRgen was actually
able to emit some of the constants Sema accepts but can't Evaluate().
For example, PR3398.

llvm-svn: 64780

llvm-svn: 64771

much pain when compiling the Linux kernel (PR3592).

llvm-svn: 64767

- Move all analyzer options logic to AnalysisConsumer.cpp.
- Unified specification of stores/constraints/output to be:
   -analyzer-output=...
   -analyzer-store=...
   -analyzer-constraints=...
  instead of -analyzer-range-constraints, -analyzer-store-basic, etc.
- Updated drivers (ccc-analyzer, scan-builds, new ccc) to obey this new
  interface
- Updated test cases to conform to new driver options

llvm-svn: 64737

functions, so if we're declaring a static we should implicitly declare
a library function by the same name (e.g., malloc, strdup). Fixes PR3592.

llvm-svn: 64736

CXXRecordDecl that is used to represent class template
specializations. These are canonical declarations that can refer to
either an actual class template specialization in the code, e.g.,

  template<> class vector<bool> { };

or to a template instantiation. However, neither of these features is
actually implemented yet, so really we're just using (and uniqing) the
declarations to make sure that, e.g., A<int> is a different type from
A<float>. Note that we carefully distinguish between what the user
wrote in the source code (e.g., "A<FLOAT>") and the semantic entity it
represents (e.g., "A<float, int>"); the former is in the sugared Type,
the latter is an actual Decl.

llvm-svn: 64716

llvm-svn: 64708

llvm-svn: 64707

llvm-svn: 64700

 - Define pow[lf]?, sqrt[lf]? as builtins.

 - Add -fmath-errno option which binds to LangOptions.MathErrno

 - Add new builtin flag Builtin::Context::isConstWithoutErrno for
   functions which can be marked as const if errno isn't respected for
   math functions. Sema automatically marks these functions as const
   when they are defined, if MathErrno=0.

 - IRgen uses const attribute on sqrt and pow library functions to
   decide if it can use the llvm intrinsic.

llvm-svn: 64689

extensions). This caught a couple bugs in our test suite :)

llvm-svn: 64686