Given the following test case:
typedef struct {
const char *name;
id field;
} Test9;
extern void doSomething(Test9 arg);
void test9() {
Test9 foo2 = {0, 0};
doSomething(foo2);
}
With a release compiler, we don't emit any message and silently ignore the
variable "foo2". With an assert compiler, we get an assertion failure.
The root cause —————————————
Back in r140457 we gave InitListChecker a verification-only mode, and will use
CanUseDecl instead of DiagnoseUseOfDecl for verification-only mode.
These two functions handle unavailable issues differently:
In Sema::CanUseDecl, we say the decl is invalid when the Decl is unavailable and
the current context is available.
In Sema::DiagnoseUseOfDecl, we say the decl is usable by ignoring the return
code of DiagnoseAvailabilityOfDecl
So with an assert build, we will hit an assertion in diagnoseListInit
assert(DiagnoseInitList.HadError() &&
"Inconsistent init list check result.");
The fix -------------------
If we follow what is implemented in CanUseDecl and treat Decls with
unavailable issues as invalid, the variable decl of “foo2” will be marked as
invalid. Since unavailable checking is processed in delayed diagnostics
(r197627), we will silently ignore the diagnostics when we find out that
the variable decl is invalid.
We add a flag "TreatUnavailableAsInvalid" for the verification-only mode.
For overload resolution, we want to say decls with unavailable issues are
invalid; but for everything else, we should say they are valid and
emit diagnostics. Depending on the value of the flag, CanUseDecl
can return different values for unavailable issues.
rdar://23557300
Differential Revision: http://reviews.llvm.org/D15314
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263149 91177308-0d34-0410-b5e6-96231b3b80d8
C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."
clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).
Fixes PR23381.
http://reviews.llvm.org/D16552
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261297 91177308-0d34-0410-b5e6-96231b3b80d8
Clang did not handles correctly inner parts of arrays/structures initializers in GNU extensions to C99 designated initializers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258668 91177308-0d34-0410-b5e6-96231b3b80d8
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
for the derived class into it. This is mostly just a cleanup, but could in
principle be a bugfix if there is some codepath that reaches here and didn't
previously require a complete type (I couldn't find any such codepath, though).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256037 91177308-0d34-0410-b5e6-96231b3b80d8
https://llvm.org/bugs/show_bug.cgi?id=20334
Unfortunately, clang currently checks for a certain brokenness of implementations of std::initializer_list in CodeGen (void
AggExprEmitter::VisitCXXStdInitializerListExpr), not in SemaInit. Until that is fixed, make sure we don't let broken attempts that are aggregates leak through into sema, which allows maintenance of expected invariants, and avoids triggering an assertion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254889 91177308-0d34-0410-b5e6-96231b3b80d8
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254554 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250090 91177308-0d34-0410-b5e6-96231b3b80d8
We took both source locations from the end of the initializer list what
the code below doesn't expect. This can lead to a crash when rendering
the diagnostic (PR24816). Assert that we have more than one element in
a scalar initializer with too many elements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248391 91177308-0d34-0410-b5e6-96231b3b80d8
While working around a bug in certain standard library implementations,
we would try to diagnose the issue so that library implementors would
fix their code. However, we assumed an entity being initialized was
a non-static data member subobject when other circumstances are
possible.
This fixes PR24526.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245675 91177308-0d34-0410-b5e6-96231b3b80d8
Without DR1579 implemented, the only case for -Wredundant-move is for a
parameter being returned with the same type as the function return type. Also
include a check to verify that the move constructor will be used by matching
nodes in the AST dump.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243594 91177308-0d34-0410-b5e6-96231b3b80d8
Dependent types can throw off the analysis for these warnings, possibly giving
conflicting warnings and fix-its. Disabling the warning in template
instantiations will prevent this problem, and will still catch the
non-dependent cases in templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243538 91177308-0d34-0410-b5e6-96231b3b80d8
error.
If the object being moved has a move constructor and a deleted copy constructor,
std::move is required, otherwise Clang will give a deleted constructor error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243463 91177308-0d34-0410-b5e6-96231b3b80d8
For designated indices use the max array size type bitwidth, not the bitwidth of the index value itself.
rdar://21942503
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243343 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
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239446 91177308-0d34-0410-b5e6-96231b3b80d8
Don't give a warning when the type being moved is a reference type. Also
uncomment two lines in the test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237607 91177308-0d34-0410-b5e6-96231b3b80d8
The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At
first glance, it appears that the const qualifier is added. Reverse the types
so that the second type is less qualified than the first.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237482 91177308-0d34-0410-b5e6-96231b3b80d8
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
Differential Revision: http://reviews.llvm.org/D7633
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236075 91177308-0d34-0410-b5e6-96231b3b80d8
We could probably make this work if we cared enough. However, we are
far outside any language rules at this point.
This fixes PR21834.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235818 91177308-0d34-0410-b5e6-96231b3b80d8
r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235166 91177308-0d34-0410-b5e6-96231b3b80d8
Given something like 'int({}, 1)', we would try to emit a diagnostic
regarding the excess element in the scalar initializer. However, we
assumed that the initializer list had an element in it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234565 91177308-0d34-0410-b5e6-96231b3b80d8
invalidate lookup_iterators and lookup_results for some name within a
DeclContext if the lookup results for a *different* name change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230121 91177308-0d34-0410-b5e6-96231b3b80d8
subobject initialization is not possible, be sure to note the overall
initialization as having failed so that overload resolution knows that the
relevant candidate is not viable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229353 91177308-0d34-0410-b5e6-96231b3b80d8
always use the normal copy-initialization rules. Remove a special case that
tries to stay within the list initialization checker here; that makes us do the
wrong thing when list-initialization of an aggregate would not perform
aggregate initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228897 91177308-0d34-0410-b5e6-96231b3b80d8
based on whether "redundant" braces are ever reasonable as part of the
initialization of the entity, rather than whether the initialization is
"top-level". In passing, add a warning flag for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228896 91177308-0d34-0410-b5e6-96231b3b80d8
initializer of the form {x}, where x is of type C or a type derived from C,
perform *non-list* initialization of the entity from x, but create a
CXXConstructExpr that knows that we used list-initialization syntax.
Plus some fixes to ensure we mangle correctly in this and related cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228276 91177308-0d34-0410-b5e6-96231b3b80d8
Use getAsArrayTypeUnsafe() instead of getUnqualifiedDesugaredType() to
get the underlying ArrayType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227129 91177308-0d34-0410-b5e6-96231b3b80d8
... when the variable's type is a typedef of a ConstantArrayType. Just
look through the typedef (and any other sugar). We only use the
constant array type here to get the element count.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227115 91177308-0d34-0410-b5e6-96231b3b80d8
clang currently calls MarkVTableUsed() for classes that get their virtual
methods called or that participate in a dynamic_cast. This is unnecessary,
since CodeGen only emits vtables when it generates constructor, destructor, and
vtt code. (*)
Note that Sema::MarkVTableUsed() doesn't cause the emission of a vtable.
Its main user-visible effect is that it instantiates virtual member functions
of template classes, to make sure that if codegen decides to write a vtable
all the entries in the vtable are defined.
While this shouldn't change the behavior of codegen (other than being faster),
it does make clang more permissive: virtual methods of templates (in particular
destructors) end up being instantiated less often. In particular, classes that
have members that are smart pointers to incomplete types will now get their
implicit virtual destructor instantiated less frequently. For example, this
used to not compile but does now compile:
template <typename T> struct OwnPtr {
~OwnPtr() { static_assert((sizeof(T) > 0), "TypeMustBeComplete"); }
};
class ScriptLoader;
struct Base { virtual ~Base(); };
struct Sub : public Base {
virtual void someFun() const {}
OwnPtr<ScriptLoader> m_loader;
};
void f(Sub *s) { s->someFun(); }
The more permissive behavior matches both gcc (where this is not often
observable, since in practice most things with virtual methods have a key
function, and Sema::DefineUsedVTables() skips vtables for classes with key
functions) and cl (which is my motivation for this change) – this fixes
PR20337. See this issue and the review thread for some discussions about
optimizations.
This is similar to r213109 in spirit. r225761 was a prerequisite for this
change.
Various tests relied on "a->f()" marking a's vtable as used (in the sema
sense), switch these to just construct a on the stack. This forces
instantiation of the implicit constructor, which will mark the vtable as used.
(*) The exception is -fapple-kext mode: In this mode, qualified calls to
virtual functions (`a->Base::f()`) still go through the vtable, and since the
vtable pointer off this doesn't point to Base's vtable, this needs to reference
Base's vtable directly. To keep this working, keep referencing the vtable for
virtual calls in apple kext mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227073 91177308-0d34-0410-b5e6-96231b3b80d8
Only the first two items for now, changing Sections 8.5.4 [dcl.init.list] paragraph 3 and 13.3.1.7 [over.match.list] paragraph 1,
so that defining class objects and character arrays using uniform initialization syntax is actually treated as list initialization
and before it is treated aggregate initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227022 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith