Add the ability to clone integer and string literals. Use it when instantiating template expressions.

llvm-svn: 67030

llvm-svn: 66997

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

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

llvm-svn: 66909

llvm-svn: 66837

llvm-svn: 66696

chosen sub-expression, rather than just evaluating the condition.

llvm-svn: 66018

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

Daniel.  Some minor fixes/cleanup.  Allow __builtin_choose_expr, 
__real__, and __imag__ in ICEs, following gcc's example.

llvm-svn: 65610

llvm-svn: 65609

is a rather big change, but I think this is the direction we want to go; 
the code is significantly shorter now, and it doesn't duplicate Evaluate 
code.  There shouldn't be any visible changes as far as I know.

There has been some movement towards putting ICE handling into 
Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate 
instead of isICE).  This patch is sort of the opposite of the approach, 
making ICE handling work without Evaluate being aware of it. I think 
this approach is better because it separates the code that does the 
constant evaluation from code that's calculating a rather 
arbitrary predicate.

The one thing I don't really like about this patch is that 
the handling of commas in C99 complicates it signficantly. (Seriously, 
what was the standards committee thinking when they wrote that 
part?) I think I've come up with a decent approach, but it doesn't feel
ideal.  I might add some way to check for evaluated commas from Evaluate 
in a subsequent patch; that said, it might not be worth bothering.

llvm-svn: 65524

The big difference here is that (like string literal) @encode has 
array type, not pointer type.

llvm-svn: 65391

of a pointer to object; This patch does this odd behavior according to
gcc.

llvm-svn: 65334

true a local pointer to objective-c object in generating
write barriers.

llvm-svn: 65290

PR3254 and part of PR3433.

The isICE changes are necessary to keep the computed results 
consistent with Evaluate.

llvm-svn: 65258

isn't getting used by Sema or CodeGen at the moment...)

llvm-svn: 65107

llvm-svn: 64961

so it shows up in -ast-dump.

llvm-svn: 64901

stuff behind a private static function.

llvm-svn: 64898

the various PPTokens that are pasted together to make it.  In the course
of working on this, I discovered ParseObjCStringLiteral which needs some
work.  I'll tackle it next.

llvm-svn: 64892

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

llvm-svn: 64865

 - This idiom ensures that the result will have the right width and
   type.

 - Tested on most of x86_64/llvm-test to satisfy my paranoia.

 - This fixes at least the following bugs:
   o UnaryTypeTraitExpr wasn't setting the width correctly.
   o Arithmetic on _Bool wasn't setting the width correctly.

   And probably a number more.

llvm-svn: 64864

with Expr::Evaluate().

llvm-svn: 64850

Doug: please verify that it is expected that LastIdx can be less that
NumInits. And perhaps add a comment so that Chris doesn't break your
code. :)

llvm-svn: 64688

llvm-svn: 64684

llvm-svn: 64681

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

1) implement parser and sema support for reading and verifying attribute(warnunusedresult).
2) rename hasLocalSideEffect to isUnusedResultAWarning, inverting the sense
   of its result.
3) extend isUnusedResultAWarning to directly return the loc and range 
   info that should be reported to the user.  Make it substantially more
   precise in some cases than what was previously reported.
4) teach isUnusedResultAWarning about CallExpr to decls that are 
   pure/const/warnunusedresult, fixing a fixme.
5) change warn_attribute_wrong_decl_type to not pass in english strings, instead,
   pass in integers and use %select.

llvm-svn: 64543

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

designating an object.

llvm-svn: 64371

llvm-svn: 64162

Deallocate the StringLiteral itself in StringLiteral::Destroy() and deallocate the string data before running StringLiteral's destructor.

llvm-svn: 64146

llvm-svn: 64145

llvm-svn: 64015

- 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

llvm-svn: 63983

ASTContext. This required changing all clients to pass in the ASTContext& to the
constructor of StringLiteral. I also changed all allocations of StringLiteral to
use new(ASTContext&).

Along the way, I updated a bunch of new()'s in StmtSerialization.cpp to use the
allocator from ASTContext& (not complete).

llvm-svn: 63958

llvm-svn: 63750

Make CodeGen produce an error if we come across a non-constant initializer list that involves the GNU array-range designator extension

llvm-svn: 63327