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

This commit adds a new attribute, "overloadable", that enables C++
function overloading in C. The attribute can only be added to function
declarations, e.g.,

  int *f(int) __attribute__((overloadable));

If the "overloadable" attribute exists on a function with a given
name, *all* functions with that name (and in that scope) must have the
"overloadable" attribute. Sets of overloaded functions with the
"overloadable" attribute then follow the normal C++ rules for
overloaded functions, e.g., overloads must have different
parameter-type-lists from each other.

When calling an overloaded function in C, we follow the same
overloading rules as C++, with three extensions to the set of standard
conversions:

  - A value of a given struct or union type T can be converted to the
    type T. This is just the identity conversion. (In C++, this would
    go through a copy constructor).
  - A value of pointer type T* can be converted to a value of type U*
    if T and U are compatible types. This conversion has Conversion
    rank (it's considered a pointer conversion in C).
  - A value of type T can be converted to a value of type U if T and U
    are compatible (and are not both pointer types). This conversion
    has Conversion rank (it's considered to be a new kind of
    conversion unique to C, a "compatible" conversion).

Known defects (and, therefore, next steps):
  1) The standard-conversion handling does not understand conversions
  involving _Complex or vector extensions, so it is likely to get
  these wrong. We need to add these conversions.
  2) All overloadable functions with the same name will have the same
  linkage name, which means we'll get a collision in the linker (if
  not sooner). We'll need to mangle the names of these functions.

llvm-svn: 64336

llvm-svn: 63983

Also, put Objective-C protocols into their own identifier
namespace. Otherwise, we find protocols when we don't want to in C++
(but not in C).

llvm-svn: 63877

llvm-svn: 63750

- Changes Lookup*Name functions to return NamedDecls, instead of
Decls. Unfortunately my recent statement that it will simplify lot of
code, was not quite right, but it simplifies some...
- Makes MergeLookupResult SmallPtrSet instead of vector, following
Douglas suggestions.
- Adds %qN format for printing qualified names to Diagnostic.
- Avoids searching for using-directives in Scopes, which are not
DeclScope, during unqualified name lookup.

llvm-svn: 63739

into the general name-lookup fold. This cleans up some ugly,
not-quite-working code in the handling of operator overloading.

llvm-svn: 63735

a.k.a. Koenig lookup) in C++. Most of the pieces are in place, but for
two:

  - In an unqualified call g(x), even if the name does not refer to
    anything in the current scope, we can still find functions named
    "g" based on ADL. We don't yet have this ability.
  - ADL will need updating for friend functions and templates.

llvm-svn: 63692

llvm-svn: 63662

using directives, from Piotr Rak!

llvm-svn: 63646

non-ambiguous name lookup results without allocating any memory, e.g.,
for sets of overloaded functions.

llvm-svn: 63549

LookupName et al. Instead, use an enum and a bool to describe its
contents.

Optimized the C/Objective-C path through LookupName, eliminating any
unnecessarily C++isms. Simplify IdentifierResolver::iterator, removing
some code and arguments that are no longer used.

Eliminated LookupDeclInScope/LookupDeclInContext, moving all callers
over to LookupName, LookupQualifiedName, or LookupParsedName, as
appropriate.

All together, I'm seeing a 0.2% speedup on Cocoa.h with PTH and
-disable-free. Plus, we're down to three name-lookup routines.

llvm-svn: 63354

that every declaration lives inside a DeclContext.

Moved several things that don't have names but were ScopedDecls (and,
therefore, NamedDecls) to inherit from Decl rather than NamedDecl,
including ObjCImplementationDecl and LinkageSpecDecl. Now, we don't
store empty DeclarationNames for these things, nor do we try to insert
them into DeclContext's lookup structure.

The serialization tests are temporarily disabled. We'll re-enable them
once we've sorted out the remaining ownership/serialiazation issues
between DeclContexts and TranslationUnion, DeclGroups, etc.

llvm-svn: 62562

llvm-svn: 62391

even when we are still defining the TagDecl. This is required so that
qualified name lookup of a class name within its definition works (see
the new bits in test/SemaCXX/qualified-id-lookup.cpp).

As part of this, move the nested redefinition checking code into
ActOnTag. This gives us diagnostics earlier (when we try to perform
the nested redefinition, rather than when we try to complete the 2nd
definition) and removes some code duplication.

llvm-svn: 62386

llvm-svn: 62287

and uninitialized use options.

llvm-svn: 62270

llvm-svn: 62250

llvm-svn: 62247

This change refactors and cleans up our handling of name lookup with
LookupDecl. There are several aspects to this refactoring:

  - The criteria for name lookup is now encapsulated into the class
  LookupCriteria, which replaces the hideous set of boolean values
  that LookupDecl currently has.

  - The results of name lookup are returned in a new class
  LookupResult, which can lazily build OverloadedFunctionDecls for
  overloaded function sets (and, eventually, eliminate the need to
  allocate member for OverloadedFunctionDecls) and contains a
  placeholder for handling ambiguous name lookup (for C++).

  - The primary entry points for name lookup are now LookupName (for
    unqualified name lookup) and LookupQualifiedName (for qualified
    name lookup). There is also a convenience function
    LookupParsedName that handles qualified/unqualified name lookup
    when given a scope specifier. Together, these routines are meant
    to gradually replace the kludgy LookupDecl, but this won't happen
    until after we have base class lookup (which forces us to cope
    with ambiguities).

  - Documented the heck out of name lookup. Experimenting a little
    with using Doxygen's member groups to make some sense of the Sema
    class. Feedback welcome!

  - Fixes some lingering issues with name lookup for
  nested-name-specifiers, which now goes through
  LookupName/LookupQualifiedName. 

llvm-svn: 62245