Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.

Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.

For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)

In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.

Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
 * if B inherits a private constructor from A, and C uses that constructor to
   construct a B, then we previously required that A befriends B and B
   befriends C, but the new rules require A to befriend C directly, and
 * if a derived class has its own constructors (and so its implicit default
   constructor is suppressed), it may still inherit a default constructor from
   a base class


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274049 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch fix the scoping of enum literal. They were not resolving
to the right type.

It was not causing any problem as one is a copy of the other one.

The literal in the switch are resolving to Sema.h:5527
```
  enum AccessResult {
    AR_accessible,
    AR_inaccessible,
    AR_dependent,
    AR_delayed
  };
```

Instead of SemaAccess.cpp:27
```
/// A copy of Sema's enum without AR_delayed.
enum AccessResult {
  AR_accessible,
  AR_inaccessible,
  AR_dependent
};
```

This issue was found by a new clang-tidy check (still on-going).

Reviewers: rsmith, aaron.ballman

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D20773

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271431 91177308-0d34-0410-b5e6-96231b3b80d8

instantiate to match a friend class declaration. It's still pretty dumb,
though.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264189 91177308-0d34-0410-b5e6-96231b3b80d8

not obvious how to access-check these, so pick a conservative rule until we get
feedback from CWG.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262966 91177308-0d34-0410-b5e6-96231b3b80d8

-Wdeprecated: SavedInstanceContext is returned by value but isn't really copyable, but it can be made movable

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244826 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243571 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240353 91177308-0d34-0410-b5e6-96231b3b80d8

The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237532 91177308-0d34-0410-b5e6-96231b3b80d8

There are a few cases where unqualified lookup can find C++ methods.
Unfortunately, none of them seem to have illegal access paths, so I
can't excercise the diagnostic source range code that I am changing
here.

Fixes PR21851, which was a crash on valid.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224471 91177308-0d34-0410-b5e6-96231b3b80d8

These note diags have the same message and can be unified further but for now
let's just bring them together.

Incidental change: Display a source range in the final attr diagnostic.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209728 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209613 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Replacing CXXRecordDecl iterators friend_begin() and friend_end() with iterator_range friends(). Updating all of the usages of the iterators with range-based for loops.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203815 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203803 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203278 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This avoids false positives from -Wmicrosoft when name lookup would
normally succeed in standard C++.  This triggered on a common CRTP
pattern in clang, where a derived class would have a private using decl
to pull in members of a dependent base:

class Verifier : InstVisitor<Verifier> {
private:
  using InstVisitor<Verifier>::visit;
  ...
  void anything() {
    visit(); // warned here
  }
};

Real access checks pass here because we're in the context of the
Verifier, but the -Wmicrosoft extension was just looking for the private
access specifier.

Reviewers: rsmith

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2679

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201019 91177308-0d34-0410-b5e6-96231b3b80d8

A return type is the declared or deduced part of the function type specified in
the declaration.

A result type is the (potentially adjusted) type of the value of an expression
that calls the function.

Rule of thumb:

  * Declarations have return types and parameters.
  * Expressions have result types and arguments.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8

It's guaranteed to be a CXXMethodDecl.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199795 91177308-0d34-0410-b5e6-96231b3b80d8

Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.

Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.

Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199794 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.

Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.

Will keep an eye on the builders and update dependent projects shortly.

No functional change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8

There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.

MicrosoftExt (aka. fms-extensions):
 Enable largely unobjectionable Microsoft language extensions to ease
 portability. This mode, also supported by gcc, is used for building software
 like FreeBSD and Linux kernel extensions that share code with Windows drivers.

MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
 Turn on a special mode supporting 'heinous' extensions for drop-in
 compatibility with the Microsoft Visual C++ product. Standards-compilant C and
 C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.

Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.

See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'

No change in behaviour.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199209 91177308-0d34-0410-b5e6-96231b3b80d8

any local extern declaration, not just a local extern function.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197000 91177308-0d34-0410-b5e6-96231b3b80d8

For an init capture, process the initialization expression
right away.  For lambda init-captures such as the following:
const int x = 10;
 auto L = [i = x+1](int a) {
   return [j = x+2,
          &k = x](char b) { };
 };
keep in mind that each lambda init-capture has to have:
 - its initialization expression executed in the context
   of the enclosing/parent decl-context.
 - but the variable itself has to be 'injected' into the
   decl-context of its lambda's call-operator (which has
   not yet been created).
Each init-expression is a full-expression that has to get
Sema-analyzed (for capturing etc.) before its lambda's
call-operator's decl-context, scope & scopeinfo are pushed on their
respective stacks.  Thus if any variable is odr-used in the init-capture
it will correctly get captured in the enclosing lambda, if one exists.
The init-variables above are created later once the lambdascope and
call-operators decl-context is pushed onto its respective stack.

Since the lambda init-capture's initializer expression occurs in the
context of the enclosing function or lambda, therefore we can not wait
till a lambda scope has been pushed on before deciding whether the
variable needs to be captured.  We also need to process all
lvalue-to-rvalue conversions and discarded-value conversions,
so that we can avoid capturing certain constant variables.
For e.g.,
 void test() {
  const int x = 10;
  auto L = [&z = x](char a) { <-- don't capture by the current lambda
    return [y = x](int i) { <-- don't capture by enclosing lambda
         return y;
    }
  };
If x was not const, the second use would require 'L' to capture, and
that would be an error.
Make sure TranformLambdaExpr is also aware of this.

Patch approved by Richard (Thanks!!) 
http://llvm-reviews.chandlerc.com/D2092

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196454 91177308-0d34-0410-b5e6-96231b3b80d8

When we check access for lookup results, make sure we propagate the
result's access to the access control APIs; this can be different from
the natural access of the declaration depending on the path used by the lookup.

PR17394.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191726 91177308-0d34-0410-b5e6-96231b3b80d8

Unlike with namespaces, searching inside of classes requires also
checking the access to correction candidates (i.e. don't suggest a
correction to a private class member for a correction occurring outside
that class and its methods or friends).

Included is a small (one line) fix for a bug, that was uncovered while
cleaning up the unit tests, where the decls from a TypoCorrection candidate
were preserved in new TypoCorrection candidates that are derived (copied)
from the old TypoCorrection--notably when creating a new candidate by
changing the NestedNameSpecifier associated with the base idenitifer.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191449 91177308-0d34-0410-b5e6-96231b3b80d8

variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.

Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191064 91177308-0d34-0410-b5e6-96231b3b80d8

No functionality change intended.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189112 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186647 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181332 91177308-0d34-0410-b5e6-96231b3b80d8

performed within the context of that class template. Patch by Ismail Pazarbasi!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180707 91177308-0d34-0410-b5e6-96231b3b80d8

access to a private member to which we have special access.

rdar://12926092

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176146 91177308-0d34-0410-b5e6-96231b3b80d8

accessible in its declaring class;  otherwise we might
fail to apply [class.protected] when considering
accessibility in derived classes.

Noticed by inspection; <rdar://13270329>.

I had an existing test wrong.  Here's why it's wrong:

Follow the rules (and notation) of [class.access]p5.
The naming class (N) is B and the context (R) is D::getX.
- 'x' as a member of B is protected, but R does not occur
  in a member or friend of a class derived from B.
- There does exist a base class of B, A, which is accessible
  from R, and 'x' is accessible at R when named in A because
  'x' as a member of A is protected and R occurs in a member
  of a class, D, that is derived from A;  however, by
  [class.protected], the class of the object expression must
  be equal to or derived from that class, and A does not
  derive from D.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175858 91177308-0d34-0410-b5e6-96231b3b80d8

uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8

Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164769 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164766 91177308-0d34-0410-b5e6-96231b3b80d8

make sure we walk up the DC chain for the current context,
rather than allowing ourselves to get switched over to the
canonical DC chain.  Fixes PR13642.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162616 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162506 91177308-0d34-0410-b5e6-96231b3b80d8

things going on here that were problematic:
  - We were missing the actual access check, or rather, it was suppressed
    on account of being a redeclaration lookup.
  - The access check would naturally happen during delay, which isn't
    appropriate in this case.
  - We weren't actually emitting dependent diagnostics associated with
    class templates, which was unfortunate.
  - Access was being propagated incorrectly for friend method declarations
    that couldn't be matched at parse-time.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161652 91177308-0d34-0410-b5e6-96231b3b80d8

This required moving the ctors for IntegerLiteral and FloatingLiteral out of
line which shouldn't change anything as they are usually called through Create
methods that are already out of line.

ASTContext::Deallocate has been a nop for a long time, drop it from ASTVector
and make it independent from ASTContext.h

Pass the StorageAllocator directly to AccessedEntity so it doesn't need to
have a definition of ASTContext around.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159718 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158981 91177308-0d34-0410-b5e6-96231b3b80d8