llvm-svn: 102112

address of overloaded function, instead of assuming that a nested name
specifier was used.  A nested name specifier is not required for static
functions.

Fixes PR6886.

llvm-svn: 102107

llvm-svn: 102098

template instantiation, since they cannot be dependent or have
dependent parts. Handle them the simple way.

llvm-svn: 102094

method being called at template definition time, retain that method
and pass it through to type-checking. We will not perform any lookup
for the method during template instantiation.

llvm-svn: 102081

Sema::BuildClassMessage; we weren't using it, and template
instantiation was faking it anyway.

llvm-svn: 102074

llvm-svn: 102073

support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.

This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.

llvm-svn: 102071

 - This fixes the last known ABI issues with ARM/APCS.

 - I've run the first 1k ABITests with '--no-unsigned --no-vector --no-complex'
   on {armv6, armv7} x {-mno-thumb, -mthumb}, and the first 10k tests for armv7
   -mthumb, for both function return types and single argument calls. These all
   pass now (they failed horribly before without --no-bitfield).

llvm-svn: 102070

immediately narrowed the access size. Fix this (and previous case) by just
choosing a better access size up-front.

llvm-svn: 102068

we have to narrow the access side immediately (can happen with packed,
-fno-bitfield-type-align).

llvm-svn: 102067

look for the const on the base type rather than on the top-level
type. Fixes PR6495 properly.

llvm-svn: 102066

elaborated-type-specifiers. Patch by Enea Zaffanella!

llvm-svn: 102065

llvm-svn: 102050

llvm-svn: 102047

llvm-svn: 102046

IRgen: Rewrite bit-field access policy to not access data beyond the bounds of the structure, which we also now verify as part of the post-layout consistency checks.
 - This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align.

 - Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues.

 - Review appreciated.

llvm-svn: 102045

llvm-svn: 102044

llvm-svn: 102043

llvm-svn: 102040

in a throw expression.  Use EmitAnyExprToMem to emit the throw expression,
which magically elides the final copy-constructor call (which raises a new
strict-compliance bug, but baby steps).  Give __cxa_throw a destructor pointer
if the exception type has a non-trivial destructor.

llvm-svn: 102039

method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:

t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
      type 'int *' [-pedantic]
  f(long_ptr);
    ^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
            ^

llvm-svn: 102038

llvm-svn: 102037

the alignment is a power of 2, even in the esoteric case of a
vector element which does not have a power-of-2 sizeof value.

llvm-svn: 102036

during message sends) over to the new initialization code and away
from the C-only CheckSingleAssignmentConstraints. The enables the use
of C++ types in method parameters and message arguments, as well as
unifying more initialiation code overall.

llvm-svn: 102035

llvm-svn: 102033

Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because

  (1) The receiver of an instance message can be a qualified name such
  as ::I or identity<I>::type.
  (2) Expressions in C++ can start with a type.

The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.

This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,

  [typename compute_receiver_type<T>::type method];

Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,

  typedef typename computed_receiver_type<T>::type Computed;
  [Computed method];

so this is merely a convenience.

Note also that message sends still cannot involve dependent types or
values.

llvm-svn: 102031

Objective-C class message expression into a type from the parser
(which was doing so in two places) to Action::getObjCMessageKind()
which, in the case of Sema, reduces the number of name lookups we need
to perform.

llvm-svn: 102026

llvm-svn: 102025

to reduce nesting. No functionality change. 

llvm-svn: 102022

sends. Major changes include:

  - Expanded the interface from two actions (ActOnInstanceMessage,
    ActOnClassMessage), where ActOnClassMessage also handled sends to
    "super" by checking whether the identifier was "super", to three
    actions (ActOnInstanceMessage, ActOnClassMessage,
    ActOnSuperMessage). Code completion has the same changes.
  - The parser now resolves the type to which we are sending a class
    message, so ActOnClassMessage now accepts a TypeTy* (rather than
    an IdentifierInfo *). This opens the door to more interesting
    types (for Objective-C++ support).
  - Split ActOnInstanceMessage and ActOnClassMessage into parser
    action functions (with their original names) and semantic
    functions (BuildInstanceMessage and BuildClassMessage,
    respectively). At present, this split is onyl used by
    ActOnSuperMessage, which decides which kind of super message it
    has and forwards to the appropriate Build*Message. In the future,
    Build*Message will be used by template instantiation.
  - Use getObjCMessageKind() within the disambiguation of Objective-C
    message sends vs. array designators.

Two notes about substandard bits in this patch:
  - There is some redundancy in the code in ParseObjCMessageExpr and
  ParseInitializerWithPotentialDesignator; this will be addressed
  shortly by centralizing the mapping from identifiers to type names
  for the message receiver.
  - There is some #if 0'd code that won't likely ever be used---it
  handles the use of 'super' in methods whose class does not have a
  superclass---but could be used to model GCC's behavior more
  closely. This code will die in my next check-in, but I want it in
  Subversion.

llvm-svn: 102021

Keep tack of whether a base in an InitializedEntity is an inherited virtual base or not. Use this in CheckConstructorAccess.

llvm-svn: 102020

exceeds the minimum ABI alignment.

llvm-svn: 102019

llvm-svn: 102015

non-bit-fields).

llvm-svn: 102014

property synthesis is using a super class ivar.

llvm-svn: 102011

Pass the InitializedEntity to Sema::CheckConstructorAccess and use it to report different diagnostics depending on which entity is being initialized.

llvm-svn: 102010

llvm-svn: 102007

because EmitBranch actually clears the insert point.  This version
actually accomplishes what I initially wanted.

llvm-svn: 101998

(if there's a current block).  The chief advantage of doing this is that it
lets us pick blocks (e.g. EH blocks) to push to the end of the function so
that fallthrough happens consistently --- i.e. it gives us the flexibility
of ordering blocks as we please without having to change the order in which
we generate code.  There are standard (?) optimization passes which can do some
of that for us, but better to generate reasonable code to begin with.

llvm-svn: 101997