llvm-svn: 150586

llvm-svn: 150585

return statements within a lambda; this diagnostic previously referred
to blocks.

llvm-svn: 150584

llvm-svn: 150583

This commit makes PrintfSpecifier::fixType() and ScanfSpecifier::fixType()
only fix a conversion specification enough that Clang wouldn't warn about it,
as opposed to always changing it to use the "canonical" conversion specifier.
(PR11975)

This preserves the user's choice of conversion specifier in cases like:

printf("%a", (long double)1);
where we previously suggested "%Lf", we now suggest "%La"

printf("%x", (long)1);
where we previously suggested "%ld", we now suggest "%lx".

llvm-svn: 150578

expression is referenced, defined, then referenced again, make sure we
instantiate it the second time it's referenced. This is the static data member
analogue of r150518.

llvm-svn: 150560

is general goodness because representations of member pointers are
not always equivalent across member pointer types on all ABIs
(even though this isn't really standard-endorsed).

Take advantage of the new information to teach IR-generation how
to do these reinterprets in constant initializers.  Make sure this
works when intermingled with hierarchy conversions (although
this is not part of our motivating use case).  Doing this in the
constant-evaluator would probably have been better, but that would
require a *lot* of extra structure in the representation of
constant member pointers:  you'd really have to track an arbitrary
chain of hierarchy conversions and reinterpretations in order to
get this right.  Ultimately, this seems less complex.  I also
wasn't quite sure how to extend the constant evaluator to handle
foldings that we don't actually want to treat as extended
constant expressions.

llvm-svn: 150551

lambda expressions. Because these issue was pulled back from Ready
status at the Kona meeting, we still emit an ExtWarn when using
default arguments for lambda expressions.

llvm-svn: 150519

template is defined, and then the specialization is referenced again, don't
forget to instantiate the template on the second reference. Use the source
location of the first reference as the point of instantiation, though.

llvm-svn: 150518

* if, switch, range-based for: warn if semicolon is on the same line.
* for, while: warn if semicolon is on the same line and either next
statement is compound statement or next statement has more
indentation.

Replacing the semicolon with {} or moving the semicolon to the next
line will always silence the warning.

Tests from SemaCXX/if-empty-body.cpp merged into SemaCXX/warn-empty-body.cpp.

llvm-svn: 150515

llvm-svn: 150503

used to construct an object of union type with a deleted default constructor
(plus fixes for some related value-initialization corner cases).

llvm-svn: 150502

Based on a patch by Vasiliy Korchagin!

llvm-svn: 150500

  [&values...] { print(values...); }

llvm-svn: 150497

Replace the simple Levenshtein edit distance for typo correction
candidates--and the hacky way adding namespace qualifiers would affect
the edit distance--with a synthetic "edit distance" comprised of several
factors and their relative weights. This also allows the typo correction
callback object to convey more information about the viability of a
correction candidate than simply viable or not viable.

llvm-svn: 150495

llvm-svn: 150475

the instantiation of a constexpr function temploid is now always constexpr, a
defaulted constexpr function temploid is often ill-formed by the rule in
[dcl.fct.def.default]p2 that an explicitly-defaulted constexpr function must
have a constexpr implicit definition. To avoid making loads of completely
reasonable code ill-formed, do not apply that rule to templates.

llvm-svn: 150453

expression with the original call operator, so that we don't try to
separately instantiate the call operator. Test and tweak a few more
bits for template instantiation of lambda expressions.

llvm-svn: 150440

constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.

llvm-svn: 150419

expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:

  - Added new entry points for TreeTransform, so that we can
  explicitly establish the link between the lambda closure type in the
  template and the lambda closure type in the instantiation.
  - Added a bit into LambdaExpr specifying whether it had an explicit
  result type or not. We should have had this anyway.

This code is 'lightly' tested.

llvm-svn: 150417

Don't route explicit construction via list-initialization through the functional cast code path. It sometimes does the wrong thing, produces horrible error messages, and is just unnecessary.

llvm-svn: 150408

synthesize a by-copy captured array in a lambda. This information will
be needed by IR generation.

llvm-svn: 150396

LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the
back-link from the closure type to the LambdaExpr, which will simplify
and lazify AST deserialization.

llvm-svn: 150393

1358, 1360, 1452 and 1453.
 - Instantiations of constexpr functions are always constexpr. This removes the
   need for separate declaration/definition checking, which is now gone.
 - This makes it possible for a constexpr function to be virtual, if they are
   only dependently virtual. Virtual calls to such functions are not constant
   expressions.
 - Likewise, it's now possible for a literal type to have virtual base classes.
   A constexpr constructor for such a type cannot actually produce a constant
   expression, though, so add a special-case diagnostic for a constructor call
   to such a type rather than trying to evaluate it.
 - Classes with trivial default constructors (for which value initialization can
   produce a fully-initialized value) are considered literal types.
 - Classes with volatile members are not literal types.
 - constexpr constructors can be members of non-literal types. We do not yet use
   static initialization for global objects constructed in this way.

llvm-svn: 150359

[dcl.type.simple]p4, which treats all xvalues as returning T&&. We had
previously implemented a pre-standard variant of decltype() that
doesn't cope with, e.g., static_ast<T&&>(e) very well.

llvm-svn: 150348

id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:

  1) Split out the check that determines whether we should capture a
  particular variable reference, along with the computation of the
  type of the field, from the actual act of capturing the
  variable. 
  2) Always compute the result of decltype() within Sema, rather than
  AST, because the decltype() computation is now context-sensitive.

llvm-svn: 150347

Proper initializer list support for new expressions and type construct expressions. Array new still missing.

llvm-svn: 150346

assignment operator, per C++ [expr.prim.lambda]p19. Make it so.

llvm-svn: 150345

Change the way we store initialization kinds so that all direct inits can distinguish between list and parens form. This allows us to correctly diagnose the last test cases from litb.

llvm-svn: 150343

llvm-svn: 150342

instead of having a special-purpose function.

- ActOnCXXDirectInitializer, which was mostly duplication of
  AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
  ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
  int x = {1};
  int x({1});
  int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
   initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
  always produces a ParenListExpr. Placed that so far failed to convert that
  back to a ParenExpr containing comma operators have been fixed. I'm pretty
  sure I could have made a crashing test case before this.

The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)

This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.

llvm-svn: 150318

Fix parsing new expressions using init lists. Probably still do the wrong thing in cases involving array new.
Show that many cases using initializer list constructors work, in that they parse and pass semantic analysis.

llvm-svn: 150316

cv-unqualified type. This is essential in order to allow move-only objects of
const-qualified types to be copy-initialized via a converting constructor.

llvm-svn: 150309

before complaining that it's incomplete.

llvm-svn: 150308

Make sure Sema creates a field for 'this' captures.  (Doug, please double-check that this is correct.)

llvm-svn: 150292

to the pattern template that it came from, otherwise we had this situation:

template <typename T1, typename T2>
struct S {
};

template <typename T>
struct S<T, int> {
};

void f() {
  S<int, int> s; // location of declaration "S<int, int>" was of "S<T1, T2>" not "S<T, int>"
}

llvm-svn: 150290

default arguments if in fact those lambdas capture any entity.

llvm-svn: 150282

llvm-svn: 150276

llvm-svn: 150267

Enhance checking for null format string literal to take into account __null.   Fixes <rdar://problem/8269537>.

llvm-svn: 150260