llvm-svn: 95805

translation units.

llvm-svn: 95794

Implement AST importing and merging for typedefs. As part of this, provide a lame implementation for importing TypeSourceInfos.

llvm-svn: 95783

merged with variables of constant array types. Also, make sure that we
call DiagnosticClient's BeginSourceFile/EndSourceFile, so that it has
a LangOptions to work with.

llvm-svn: 95782

I don't have time to refix it for now.

llvm-svn: 95733

into another AST, including their include history. Here's an example
error that involves a conflict merging a variable with different types
in two translation units (diagnosed in the third AST context into
which everything is merged).

/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var2.c:3:5:
error: external variable 'x2' declared with incompatible types in
different translation units ('int' vs. 'double')
int x2;
    ^
In file included from
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.c:3:
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.h:1:8:
note: declared here with type 'double'
double x2;
       ^

Although we maintain include history, we do not maintain macro
instantiation history across a merge. Instead, we map down to the
spelling location (for now!).

llvm-svn: 95732

llvm-svn: 95706

it available within the AST library, of which Sema is one client. No
functionality change.

llvm-svn: 95701

context with the AST importer. WIP, still useless but at least it has
a test.

llvm-svn: 95683

not *any* base up to now has produced a path.  Fixes PR 6254.

I'll do the access-control part of this patch RSN.

llvm-svn: 95638

ObjCObjectPointerType AST node by allocating the list of protocols
after the type node itself. No functionality change.

llvm-svn: 95597

attribute properly and avoid bogus warning. This is
an objective-c fix only. objective-c++ follows different code
pass and requires separate fix (which will come at a later time).
Fixes radar 7214820.

llvm-svn: 95571

the AST importer. This doesn't actually do anything (yet), because we
don't have driver logic for merging ASTs.

llvm-svn: 95570

llvm-svn: 95553

llvm-svn: 95543

out-of-line initializers as integer constant expressions.  Fixes PR6206.

llvm-svn: 95463

follows (as conservatively as possible) gcc's current behavior:  attributes
written on return types that don't apply there are applied to the function
instead, etc.  Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks).  Consistently consume CC/noreturn
information throughout codegen;  enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().

llvm-svn: 95436

one context and import them into another context, merging them
according to language-specific rules. This is a skeleton. It doesn't
work, it isn't testable, but I want it in version control.

llvm-svn: 95395

Fixes latent and not-so-latent objc++ and blocks++ bugs.

llvm-svn: 95340

llvm-svn: 95335

of a C++ record.  Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition.  Also cuts down on memory usage.

llvm-svn: 95330

ton of potential crashes of the same kind. The fundamental problem is
that type creation was following a dangerous pattern when using its
FoldingSets:
  1) Use FindNodeOrInsertPos to see if the type is available
  2) If not, and we aren't looking at a canonical type, build the
  canonical type
  3) Build and insert the new node into the FoldingSet

The problem here is that building the canonical type can, in very rare
circumstances, force the hash table inside the FoldingSet to
reallocate. That invalidates the insertion position we computed in
step 1, and in step 3 we end up inserting the new node into the wrong
place. BOOM!

I've audited all of ASTContext, fixing this problem everywhere I found
it. The vast majority of wrong code was C++-specific (and *ahem*
written by me), so I also audited other major folding sets in the C++
code (e.g., template specializations), but found no other instances of
this problem.

llvm-svn: 95315

llvm-svn: 95291

Don't try to fold DeclRefExprs that point to ParmVarDecls. This had the side-effect of always folding the expression to the default argument of the parameter. For example:

void f(int a = 10) {
  return a;
}

would always return 10, regardless of the passed in argument.

This fixes another 600 test failures. We're now down to only 137 failures!

llvm-svn: 95262

remove some age-old FIXMEs and C++ workarounds within the
type-compatibility logic.

llvm-svn: 95249

working code, for no apparent reason.

llvm-svn: 95244

with a function with a prototype, treat parameters of enumeration type
based on the enumeration type's promotion type.

llvm-svn: 95238

that is in an anonymous namespace, give that function or variable
internal linkage.

This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:

  - Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
    when the declaration is in an anonymous namespace.
  - Added Type::getLinkage() to determine the linkage of a type, which
    is defined as the minimum linkage of the types (when we're dealing
    with a compound type that is not a struct/class/union).
  - Extended NamedDecl::getLinkage() to consider the linkage of the
    template arguments and template parameters of function template
    specializations and class template specializations.
  - Taught code generation to rely on NamedDecl::getLinkage() when
    determining the linkage of variables and functions, also
    considering the linkage of the types of those variables and
    functions (C++ only). Map UniqueExternalLinkage to internal
    linkage, taking out the explicit checks for
    isInAnonymousNamespace().

This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:

LLVM:
  Expected Passes    : 4006
  Expected Failures  : 32
  Unsupported Tests  : 40
  Unexpected Failures: 736

Clang:
  Expected Passes    : 1903
  Expected Failures  : 14
  Unexpected Failures: 75

Overall:
  Expected Passes    : 5909
  Expected Failures  : 46
  Unsupported Tests  : 40
  Unexpected Failures: 811

Still to do:
  - Improve testing
  - Check whether we should allow the presence of types with
  InternalLinkage (in addition to UniqueExternalLinkage) given
  variables/functions internal linkage in C++, as mentioned in
  PR5792. 
  - Determine how expensive the getLinkage() calls are in practice;
  consider caching the result in NamedDecl.
  - Assess the feasibility of Chris's idea in comment #1 of PR5792.

llvm-svn: 95216

Implement Doug's suggestion. Eliminate the Stmts pointer from CXXTryStmt and instead allocate the statements after the object.

llvm-svn: 95199

llvm-svn: 95190

- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon.  This also simplifies the code generated by the GNU runtime a bit.  

- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.

- Recognise @selector() expressions as valid static initialisers (as GCC does).

- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants.  These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.

- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector.  This is needed for generating typed selectors from @selector() expressions (as GCC does).  Ideally, this information should be stored in the Selector, but that would be an invasive change.  We should eventually add checks for common uses of @selector() expressions.  Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:

- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
           withObject: (id)object;

Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature.  We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.

- Made @selector() expressions emit type info if available and the runtime supports it.

Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac.  This currently just assert()s.

llvm-svn: 95189

appropriately.  Call out a few missing cases in the expression mangler.

llvm-svn: 95176

WHAT!?!

It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.

In this commit:
  - Enum types with a promotion type of "int" or "unsigned int" are
  promotable.
  - Tweaked the computation of promotable types for enums
  - For all of the ABIs, treat enum types the same way as their
  underlying types (*not* their promotion types) for argument passing
  and return values
  - Extend the ABI tester with support for enumeration types

llvm-svn: 95117

llvm-svn: 95106

llvm-svn: 95096

UnresolvedMemberExpr and employ it in a few places where it's useful.

llvm-svn: 95072

In C++, an initializer on a variable doesn't necessarily mean it's the definition. With that in mind, rename getDefinition to getAnyInitializer (to distinguish it from getInit) and reimplement it in terms of isThisDeclarationADefinition. Update all code to use this new function.

llvm-svn: 94999

Add VarDecl::isThisDeclarationADefinition(), which properly encapsulates the logic for when a variable declaration is a (possibly tentativ) definition. Add a few functions building on this, and shift C tentative definition handling over to this new functionality. This shift also kills the Sema::TentativeDefinitions map and instead simply stores all declarations in the renamed list. The correct handling for multiple tentative definitions is instead shifted to the final walk of the list.

llvm-svn: 94968

llvm-svn: 94963

(necessarily simultaneous) changes:

  - CXXBaseOrMemberInitializer now contains only a single initializer
    rather than a set of initialiation arguments + a constructor. The
    single initializer covers all aspects of initialization, including
    constructor calls as necessary but also cleanup of temporaries
    created by the initializer (which we never handled
    before!).

  - Rework + simplify code generation for CXXBaseOrMemberInitializers,
    since we can now just emit the initializer as an initializer.

  - Switched base and member initialization over to the new
    initialization code (InitializationSequence), so that it

  - Improved diagnostics for the new initialization code when
    initializing bases and members, to match the diagnostics produced
    by the previous (special-purpose) code.

  - Simplify the representation of type-checked constructor initializers in
    templates; instead of keeping the fully-type-checked AST, which is
    rather hard to undo at template instantiation time, throw away the
    type-checked AST and store the raw expressions in the AST. This
    simplifies instantiation, but loses a little but of information in
    the AST.

  - When type-checking implicit base or member initializers within a
    dependent context, don't add the generated initializers into the
    AST, because they'll look like they were explicit.

  - Record in CXXConstructExpr when the constructor call is to
  initialize a base class, so that CodeGen does not have to infer it
  from context. This ensures that we call the right kind of
  constructor.

There are also a few "opportunity" fixes here that were needed to not
regress, for example:

  - Diagnose default-initialization of a const-qualified class that
    does not have a user-declared default constructor. We had this
    diagnostic specifically for bases and members, but missed it for
    variables. That's fixed now.

  - When defining the implicit constructors, destructor, and
    copy-assignment operator, set the CurContext to that constructor
    when we're defining the body.

llvm-svn: 94952