lambda closure type's function pointer conversion over user-defined
conversion via a lambda closure type's block pointer conversion,
always. This is a preference for more-standard code (since blocks
are an extension) and a nod to efficiency, since function pointers
don't require any memory management. Fixes PR12063.
llvm-svn: 151170
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).
Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.
llvm-svn: 151131
function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.
This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.
Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.
llvm-svn: 151117
that 'this' can be used in the brace-or-equal-initializer of a
non-static data member, and C++11 [expr.prim.lambda]p9, which says
that lambda expressions not in block scope can have no captures, side
fully with C++11 [expr.prim.general]p4 by allowing 'this' to be
captured within these initializers. This seems to be the intent of
non-static data member initializers.
llvm-svn: 151101
arguments. There are two aspects to this:
- Make sure that when marking the declarations referenced in a
default argument, we don't try to mark local variables, both because
it's a waste of time and because the semantics are wrong: we're not
in a place where we could capture these variables again even if it
did make sense.
- When a lambda expression occurs in a default argument of a
function template, make sure that the corresponding closure type is
considered dependent, so that it will get properly instantiated. The
second bit is a bit of a hack; to fix it properly, we may have to
rearchitect our handling of default arguments, parsing them only
after creating the function definition. However, I'd like to
separate that work from the lambdas work.
llvm-svn: 151076
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.
llvm-svn: 151001
eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner
captures.
This new scheme makes two passes over the capturing scope stack. The
first pass goes up the stack (from innermost to outermost), assessing
whether the capture looks feasible and stopping when it either hits
the scope where the variable is declared or when it finds an existing
capture. The second pass then walks down the stack (from outermost to
innermost), capturing the variable at each step and updating the
captured type and the type that an expression referring to that
captured variable would see. It also checks type-specific
restrictions, such as the inability to capture an array within a
block. Note that only the first odr-use of each
variable needs to do the full walk; subsequent uses will find the
capture immediately, so multiple walks need not occur.
The same routine that builds the captures can also compute the type of
the captures without signaling errors and without actually performing
the capture. This functionality is used to determine the type of
declaration references as well as implementing the weird decltype((x))
rule within lambda expressions.
The capture code now explicitly takes sides in the debate over C++
core issue 1249, which concerns the type of captures within nested
lambdas. We opt to use the more permissive, more useful definition
implemented by GCC rather than the one implemented by EDG.
llvm-svn: 150875
even if they are not within a function scope. Teach template
instantiation to treat them as such, and make sure that we have a
local instantiation scope when instantiating default arguments and
static data members.
llvm-svn: 150725
* Fix bug when determining whether && / || are potential constant expressions
* Try harder when determining whether ?: is a potential constant expression
* Produce a diagnostic on sizeof(VLA) to provide a better source location
llvm-svn: 150657
pointers and block pointers). We use dummy definitions to keep the
invariant that an implicit, used definition has a body; IR generation
will substitute the actual contents, since they can't be represented
as C++.
For the block pointer case, compute the copy-initialization needed to
capture the lambda object in the block, which IR generation will need
later.
llvm-svn: 150645
function, provide a specialized diagnostic that indicates the kind of
special member function (default constructor, copy assignment
operator, etc.) and that it was implicitly deleted. Add a hook where
we can provide more detailed information later.
llvm-svn: 150611
to be core constant expressions (including pointers and references to
temporaries), and makes constexpr calculations Turing-complete. A Turing machine
simulator is included as a testcase.
This opens up the possibilty of removing CCValue entirely, and removing some
copies from the constant evaluator in the process, but that cleanup is not part
of this change.
llvm-svn: 150557
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
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
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
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
default is '=', and reword the warning about explicitly capturing
'this' in such lambdas to indicate that only explicit capture is
banned.
Introduce Fix-Its for this and other "save the programmer from
themself" rules regarding what can be explicitly captured and what
must be implicitly captured.
llvm-svn: 150256
nested captures. We currently don't get odr-use correct in array
bounds, so that bit is commented out while we sort out what we need to
do.
llvm-svn: 150255
have finished parsing the body, so that name lookup will never find
anything within the closure type. Then, add this operator() and the
conversion function (if available) before completing the class.
llvm-svn: 150252
o Correct the handling of the restrictions on usage of cv-qualified and
ref-qualified function types.
o Fix a bug where such types were rejected in template type parameter default
arguments, due to such arguments not being treated as a template type arg
context.
o Remove the ExtWarn for usage of such types as template arguments; that was
a standard defect, not a GCC extension.
o Improve the wording and unify the code for diagnosing cv-qualifiers with the
code for diagnosing ref-qualifiers.
llvm-svn: 150244
incomplete class type which has an overloaded operator&, it's now just
unspecified whether the overloaded operator or the builtin is used.
llvm-svn: 150234
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.
llvm-svn: 150168
empty union. This still rejects anonymous member structs or unions which only
contain such empty class types, pending standard wording defining exactly what
an empty class type is.
llvm-svn: 150157
- Complete the lambda class when we finish the lambda expression
(previously, it was left in the "being completed" state)
- Actually return the LambdaExpr object and bind to the resulting
temporary when needed.
- Detect when cleanups are needed while capturing a variable into a
lambda (e.g., due to default arguments in the copy constructor), and
make sure those cleanups apply for the whole of the lambda
expression.
llvm-svn: 150123
only add 'const' for variables captured by copy in potentially
evaluated expressions of non-mutable lambdas. (The "by copy" part was
missing).
llvm-svn: 150088
the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit
out of the sign bit still does. As promised to Howard :)
The suppression of the potential constant expression checking in system headers
is also removed, since the problem it was working around is gone.
llvm-svn: 150059
- Capturing variables by-reference and by-copy within a lambda
- The representation of lambda captures
- The creation of the non-static data members in the lambda class
that store the captured variables
- The initialization of the non-static data members from the
captured variables
- Pretty-printing lambda expressions
There are a number of FIXMEs, both explicit and implied, including:
- Creating a field for a capture of 'this'
- Improved diagnostics for initialization failures when capturing
variables by copy
- Dealing with temporaries created during said initialization
- Template instantiation
- AST (de-)serialization
- Binding and returning the lambda expression; turning it into a
proper temporary
- Lots and lots of semantic constraints
- Parameter pack captures
llvm-svn: 149977
can't produce a constant expression is not ill-formed (so long as some
instantiation of that function can produce a constant expression).
llvm-svn: 149802
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
template without a corresponding parameter pack, don't immediately
substitute the alias template. This is under discussion in the C++
committee, and may become ill-formed, but for now we match GCC.
llvm-svn: 149697
template. Such pack expansions can easily fail at template
instantiation time, if the expanded parameter packs are of the wrong
length. Fixes <rdar://problem/10040867>, PR9021, and the example that
came up today at Going Native.
llvm-svn: 149685
* support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11
* check for unspecified values in pointer comparisons and pointer subtractions
llvm-svn: 149578
This is a mess. According to the C++11 standard, pointer subtraction only has
undefined behavior if the difference of the array indices does not fit into a
ptrdiff_t.
However, common implementations effectively perform a char* subtraction first,
and then divide the result by the element size, which can cause overflows in
some cases. Those cases are not considered to be undefined behavior by this
change; perhaps they should be.
llvm-svn: 149490
- Actually building the var -> capture mapping properly (there was an off-by-one error)
- Keeping track of the source location of each capture
- Minor QoI improvements, e.g, highlighing the prior capture if
there are multiple captures, pointing at the variable declaration we
found if we reject it.
As part of this, add standard citations for the various semantic
checks we perform, and note where we're not performing those checks as
we should.
llvm-svn: 149462
function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.
llvm-svn: 149108
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
to an error, so that users can turn them off if necessary. Note that
this does *not* change the behavior of in a SFINAE context, where we
still flag an error even if the warning is disabled. This matches
GCC's behavior.
llvm-svn: 148701
values and non-type template arguments of integral and enumeration types.
This change causes some legal C++98 code to no longer compile in C++11 mode, by
enforcing the C++11 rule that narrowing integral conversions are not permitted
in the final implicit conversion sequence for the above cases.
llvm-svn: 148439
for it to be used in converted constant expression checking, and fix a couple
of issues:
- Conversion operators implicitly invoked prior to the narrowing conversion
were not being correctly handled when determining whether a constant value
was narrowed.
- For conversions from floating-point to integral types, the diagnostic text
incorrectly always claimed that the source expression was not a constant
expression.
llvm-svn: 148381
not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.
llvm-svn: 148209
- If the declarator is at the start of a line, and the previous line contained
another declarator and ended with a comma, then that comma was probably a
typo for a semicolon:
int n = 0, m = 1, l = 2, // k = 5;
myImportantFunctionCall(); // oops!
- If removing the parentheses would correctly initialize the object, then
produce a note suggesting that fix.
- Otherwise, if there is a simple initializer we can suggest which performs
value-initialization, then provide a note suggesting a correction to that
initializer.
Sema::Declarator now tracks the location of the comma prior to the declarator in
the declaration, if there is one, to facilitate providing the note. The code to
determine an appropriate initializer from the -Wuninitialized warning has been
factored out to allow use in both that and -Wvexing-parse.
llvm-svn: 148072
zero-initialize the first union member. Also fix a bug where initializing an
array of types compatible with wchar_t from a wide string literal failed in C,
and fortify the C++ tests in this area. This part can't be tested without a code
change to enable array evaluation in C (where an existing test fails).
llvm-svn: 148035
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
llvm-svn: 147824
pointer-arithmetic-related undefined behavior and unspecified results. We
continue to fold such values, but now notice they aren't constant expressions.
llvm-svn: 147659
the Semantic Powers to only warn on class types (or dependent types), where the
constructor or destructor could do something interesting.
llvm-svn: 147642
scope, when no other indication is provided that the user intended to declare a
function rather than a variable.
Remove some false positives from the existing 'parentheses disambiguated as a
function' warning by suppressing it when the declaration is marked as 'typedef'
or 'extern'.
Add a new warning group -Wvexing-parse containing both of these warnings.
The new warning is enabled by default; despite a number of false positives (and
one bug) in clang's test-suite, I have only found genuine bugs with it when
running it over a significant quantity of real C++ code.
llvm-svn: 147599
Also temporarily remove the assumption from IR gen that we can emit IR for every
constant we can fold, since it isn't currently true in C++11, to fix PR11676.
Original comment from r147271:
constexpr: perform zero-initialization prior to / instead of performing a
constructor call when appropriate. Thanks to Eli for spotting this.
llvm-svn: 147384
Explicit instantiations following specializations are no-ops and hence have
no PointOfInstantiation. That was done correctly in most cases, but for a
specialization -> instantiation decl -> instantiation definition chain, the
definition didn't realize that it was a no-op. Fix that.
Also, when printing diagnostics for these no-ops, get the diag location from
the decl name location.
Add many test cases, one of them not yet passing (but it failed the same way
before this change). Fixes http://llvm.org/pr11558 and more.
llvm-svn: 147225
Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.
The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.
Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.
llvm-svn: 146955
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
extern const int a;
const int n = a;
const int a = 5;
int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
llvm-svn: 146856
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
llvm-svn: 146749
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
freebsd bots happy. In the longer term, we should have a mechanism for moving
constexpr recursion off the call stack, to support the default limit of 512
suggested by the standard.
llvm-svn: 146596
methods) to bool. E.g.
void foo() {}
if (f) { ... // <- Warns here.
}
Only applies to non-weak functions, and does not apply if the function address
is taken explicitly with the addr-of operator.
llvm-svn: 145849
when computing the exception specification of a copy or move constructor,
ignore non-static data member initializers. Fixes PR11418 /
<rdar://problem/10478642>.
llvm-svn: 145269
or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.
llvm-svn: 144468
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
llvm-svn: 144028
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
but trivially constructible and destructible variables in C++11 mode. Also
incidentally improve the precision of the wording for jump diagnostics in C++98
mode.
llvm-svn: 142619
Add test that a variadic base list which expands to 0 bases doesn't make the
class a non-aggregate. This test passed before the change, too.
llvm-svn: 142411
through varargs. This only happens when we're in an unevaluated
context, where we don't want to trigger an error anyway. Fixes PR11131
/ <rdar://problem/10288375>.
llvm-svn: 141986
part of template argument deduction is ill-formed, we mark it as
invalid and treat it as a deduction failure. If we happen to find that
specialization again, treat it as a deduction failure rather than
silently building a call to the declaration.
Fixes PR11117, a marvelous bug where deduction failed after creating
an invalid specialization, causing overload resolution to pick a
different candidate. Then we performed a similar overload resolution
later, and happily picked the invalid specialization to
call... resulting in a silent link failure.
llvm-svn: 141809
We'd also like for "C++11" or "c++11" to be used for the warning
groups, but without removing the old warning flags. Patches welcome;
I've run out of time to work on this today.
llvm-svn: 141801
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
constexpr constructor templates. Such checking is optional, and currently hard
to get right since clang doesn't generate implicit member initializers until
instantiation (even for non-dependent members).
This is needed for clang to accept libstdc++ from g++4.6 in c++0x mode.
llvm-svn: 141547
initializer to update the type of the declaration. For example, this
allows us to determine the size of an incomplete array from its
initializer. Fixes PR10288.
llvm-svn: 141543
Begin with just default constructors. One note is that as a side effect
of this, a conformance test was removed on the basis that this is almost
certainly a defect as with most of union initialization. As it is, clang
does not implement union initialization close to the standard as it's
quite broken as written. I hope to write a paper addressing the issues
eventually.
llvm-svn: 141528
conversion function whose result type is an lvalue reference. The
initialization code already handled this properly, but overload
resolution was allowing the binding. Fixes PR11003 /
<rdar://problem/10233078>.
llvm-svn: 141137
part on patches by Peter Collingbourne.
We diverge from the C++11 standard in a few areas, mostly related to checking
constexpr function declarations, and not just definitions. See WG21 paper
N3308=11-0078 for details.
Function invocation substitution is not available in this patch; constexpr
functions cannot yet be used from within constant expressions.
llvm-svn: 140926
We had an extension which allowed const static class members of floating-point type to have in-class initializers, 'as a C++0x extension'. However, C++0x does not allow this. The extension has been kept, and extended to all literal types in C++0x mode (with a fixit to add the 'constexpr' specifier).
llvm-svn: 140801
- This fixes a host of obscure bugs with regards to how warning mapping options composed with one another, and I believe makes the code substantially easier to read and reason about.
llvm-svn: 140770
This model uses the 'landingpad' instruction, which is pinned to the top of the
landing pad. (A landing pad is defined as the destination of the unwind branch
of an invoke instruction.) All of the information needed to generate the correct
exception handling metadata during code generation is encoded into the
landingpad instruction.
The new 'resume' instruction takes the place of the llvm.eh.resume intrinsic
call. It's lowered in much the same way as the intrinsic is.
llvm-svn: 140049
synthesized move assignment within an implicitly-defined move
assignment operator, be sure to treat the derived-to-base cast as an
xvalue (rather than an lvalue). Otherwise, we'll end up getting the
wrong constructor.
Optimize a direct call to a trivial move assignment operator to an
aggregate copy, as we do for trivial copy assignment operators, and
update the the assertion in CodeGenFunction::EmitAggregateCopy() to
cope with this optimization.
Fixes PR10860.
llvm-svn: 139143
semantic analysis when taking the address of an xvalue. Instead, just
build the unary operator directly, since it's safe to do so (from the
IRgen and AST perspectives) for any glvalue. Fixes PR10822.
llvm-svn: 138935
collision between C99 hexfloats and C++0x user-defined literals by
giving C99 hexfloats precedence. Also, warning about user-defined
literals that conflict with hexfloats and those that have names that
are reserved by the implementation. Fixes <rdar://problem/9940194>.
llvm-svn: 138839
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
llvm-svn: 138821
qualification of a type doesn't affect whether a conversion is a narrowing
conversion.
This doesn't work in template cases because SubstTemplateTypeParmType gets in
the way.
llvm-svn: 138735
to varargs functions in unevaluated contexts. AFAICT, there is no
standards justification for this, but it matches what other compilers do
and therefore preserves compatibility with certain template metaprogramming
idioms.
Should fix self-host.
llvm-svn: 138715
a member template, e.g.,
x.f<int>
if we have found a template in the type of x, but the lookup in the
current scope is ambiguous, just ignore the lookup in the current
scope. Fixes <rdar://problem/9915664>.
llvm-svn: 137255
[dcl.init.list] as is possible without generalized initializer lists or full
constant expression support, and adds a c++0x-compat warning in C++98 mode.
The FixIt currently uses a typedef's basename without qualification, which is
likely to be incorrect on some code. If it's incorrect on too much code, we
should write a function to get the string that refers to a type from a
particular context.
The warning is currently off by default. I'll fix LLVM and clang before turning
it on.
llvm-svn: 136181
Revert "For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either."
This reverts commit ac420c5053d6aa41d59f782caad9e46e5baaf2c2.
llvm-svn: 135210
template<typename T> struct S { } f() { return 0; }
This case now produces a missing ';' diagnostic, since that seems like a much more likely error than an attempt to declare a function or variable in addition to the class template.
Treat this
llvm-svn: 135195
This is a first baby step towards supporting generalized initializer lists. This also removes an aggregate
test case that was just plain wrong, assuming that non-aggregates couldn't be initialized with initializer lists
in C++11 mode.
llvm-svn: 135177
throw-expressions, such that we don't consider the NRVO when the
non-volatile automatic object comes from outside the innermost try
scope (C++0x [class.copymove]p13). In C++98/03, our ASTs were
incorrect but it didn't matter because IR generation doesn't actually
apply the NRVO here. In C++0x, however, we were moving from an object
when in fact we should have copied from it. Fixes PR10142 /
<rdar://problem/9714312>.
llvm-svn: 134548
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
static_cast<NSString**>(&x); // Casting as (__strong NSString**).
This currently only works for C++ named casts, C casts to follow.
llvm-svn: 134273
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
deducing template parameter types. Recently Clang began enforcing the
more strict checking that the argument type and the deduced function
parameter type (after substitution) match, but that only consideres
qualification conversions.
One problem with this patch is that we check noreturn conversions and
qualification conversions independently. If a valid conversion would
require *both*, perhaps interleaved with each other, it will be
rejected. If this actually occurs (I'm not yet sure it does) and is in
fact a problem (I'm not yet sure it is), there is a FIXME to implement
more intelligent conversion checking.
However, this step at least allows Clang to resume accepting valid code
we're seeing in the wild.
llvm-svn: 133327
storage specifier is different from the storage specifier on the
template. If that storage specifier is the same, then we only warn.
Thanks to John for the prodding.
llvm-svn: 133236
checks that the deduced argument type for a function call matches the
actual argument type provided. The only place we've found where the
consistency checking should actually cause template argument deduction
failure is due to qualifier differences that don't fall into the realm
of qualification conversions (which are *not* checked when we
initially perform deduction). However, we're performing the full
checking as specified in the standard to ensure that no other cases
exist.
Fixes PR9233 / <rdar://problem/9039590>.
llvm-svn: 133163
in a noexcept exception specification because it isn't part of the
canonical type. This ensures that we keep the exact expression written
in the noexcept exception specification, rather than accidentally
"adopting" a previously-written and canonically "equivalent" function
prototype. Fixes PR10087.
llvm-svn: 132998
specializations within an explicit instantiation to default to off
(enabled by -pedantic). Nobody else seem to implement C++
[temp.explicit]p3. Fixes PR10093.
llvm-svn: 132704
Douglas Gregor