Specifically, when we have this situation:
struct A {
template <typename T> struct B {
int m1 = sizeof(A);
};
B<int> m2;
};
We can't parse m1's initializer eagerly because we need A to be
complete. Therefore we wait until the end of A's class scope to parse
it. However, we can trigger instantiation of B before the end of A,
which will attempt to instantiate the field decls eagerly, and it would
build a bad field decl instantiation that said it had an initializer but
actually lacked one.
Fixed by deferring instantiation of default member initializers until
they are needed during constructor analysis. This addresses a long
standing FIXME in the code.
Fixes PR19195.
Reviewed By: rsmith
Differential Revision: http://reviews.llvm.org/D5690
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222192 91177308-0d34-0410-b5e6-96231b3b80d8
The check for unnamed members was intended to skip unnamed bitfields,
but it ended up skipping unnamed structs. This lead to an assertion in
IRGen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221818 91177308-0d34-0410-b5e6-96231b3b80d8
before retrying the initialization to produce diagnostics. Otherwise, we may
fail to produce any diagnostics, and silently produce invalid AST in a -Asserts
build. Also add a note to this codepath to make it more clear why we were
trying to create a temporary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217197 91177308-0d34-0410-b5e6-96231b3b80d8
Clang used a custom implementation of lookup when handling designated
initializers. The custom code was not particularly optimized and relied
on standard lookup for typo-correction anyway.
This custom code has to go, it doesn't properly support MSVC-style
anonymous structs embedded inside other records; replace it with the
typo-correction path.
This has the side effect of speeding up semantic handling of the fields
for a designated initializer while simplifying the code at the same
time.
This fixes PR20573.
Differential Revision: http://reviews.llvm.org/D4839
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215372 91177308-0d34-0410-b5e6-96231b3b80d8
or a class derived from T. We already supported this when initializing
_Atomic(T) from T for most (and maybe all) other reasonable values of T.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214390 91177308-0d34-0410-b5e6-96231b3b80d8
This tweaks the diagnostic wording slighly, and adds a fixit on a note.
An alternative would be to add the fixit directly on the diagnostic, see
the review thread linked to from the bug for a few notes on that approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213725 91177308-0d34-0410-b5e6-96231b3b80d8
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213443 91177308-0d34-0410-b5e6-96231b3b80d8
If, during the initial parse of a template, we perform aggregate initialization
and form an implicit value initialization for an array type, then when we come
to instantiate the template and redo the initialization step, we would try to
match the implicit value initialization up against an array *element*, not to
the complete array.
Remarkably, we've had this bug since ~the dawn of time, but only noticed it
recently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213332 91177308-0d34-0410-b5e6-96231b3b80d8
-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213224 91177308-0d34-0410-b5e6-96231b3b80d8
constructor (and pass it an implicitly-generated std::initializer_list object),
be sure to mark the resulting construction as list-initialization. This fixes
an assert in template instantiation where we previously thought we'd got direct
non-list initialization without any parentheses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213201 91177308-0d34-0410-b5e6-96231b3b80d8
Also, forgot to say in the commit message of r212238: Library authors will
see a warning about this issue if they build with -Wsystem-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212243 91177308-0d34-0410-b5e6-96231b3b80d8
r210091 made initialization checking more strict in c++11 mode. LWG2193 is
about changing standard libraries to still be valid under these new rules,
but older libstdc++ (e.g. libstdc++4.6 in -D_GLIBCXX_DEBUG=1 mode, or stlport)
do not implement that yet. So fall back to the C++03 semantics for container
classes in system headers below the std namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212238 91177308-0d34-0410-b5e6-96231b3b80d8
and is unrelated to the NEON intrinsics in arm_neon.h. On little
endian machines it works fine, however on big endian machines it
exhibits surprising behaviour:
uint32x2_t x = {42, 64};
return vget_lane_u32(x, 0); // Will return 64.
Because of this, explicitly call out that it is unsupported on big
endian machines.
This patch will emit the following warning in big-endian mode:
test.c:3:15: warning: vector initializers are a GNU extension and are not compatible with NEON intrinsics [-Wgnu]
int32x4_t x = {0, 1, 2, 3};
^
test.c:3:15: note: consider using vld1q_s32() to initialize a vector from memory, or vcombine_s32(vcreate_s32(), vcreate_s32()) to initialize from integer constants
1 warning generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211362 91177308-0d34-0410-b5e6-96231b3b80d8
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211005 91177308-0d34-0410-b5e6-96231b3b80d8
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210091 91177308-0d34-0410-b5e6-96231b3b80d8
just the extremely specific case of a trailing array element that couldn't be
initialized because the default constructor for the element type is deleted.
Also reword the diagnostic to better match our other context diagnostics and to
prepare for the implementation of core issue 1070.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210083 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
The conventional form is '<action> to silence this warning'.
Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209052 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207776 91177308-0d34-0410-b5e6-96231b3b80d8
Replacing llvm::copy changes with SmallVector range-based construction which is a considerably cleaner approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203461 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
cstring, converted to NSString, produce the
matching AST for it. This also required some
refactoring of the previous code. // rdar://14106083
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197605 91177308-0d34-0410-b5e6-96231b3b80d8
of objc_bridge_related attribute; eliminate
unnecessary diagnostics which is issued elsewhere,
fixit now produces a valid AST tree per convention.
This results in some simplification in handling of
this attribute as well. // rdar://15499111
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197436 91177308-0d34-0410-b5e6-96231b3b80d8
attribute in sema and issuing a variety of diagnostics lazily
for misuse of this attribute (and what to do) when converting
from CF types to ObjectiveC types (and vice versa).
// rdar://15499111
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196629 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196466 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
substitution failure, allow a flag to be set on the Diagnostic object,
to mark it as 'causes substitution failure'.
Refactor Diagnostic.td and the tablegen to use an enum for SFINAE behavior
rather than a bunch of flags.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194444 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith