conflicting attribute, warn about the conflict and pick a "winning"
attribute to preserve, instead of emitting an error. This matches the
behavior when the conflicting attributes are on different declarations.
Along the way I discovered that conflicts involving __forceinline were
reported as 'always_inline' (alternate spelling, same attribute) so
fixed that up to report the attribute as spelled in the source.
llvm-svn: 225813
-Wself-move is similiar to -Wself-assign. This warning is triggered when
a value is attempted to be moved to itself. See r221008 for a bug that
would have been caught with this warning.
llvm-svn: 225581
We have a diagnostic describing that constexpr changed in C++14 when
compiling in C++11 mode. While doing this, it examines the previous
declaration and assumes that it is a function. However it is possible,
in the context of error recovery, for this to not be the case.
llvm-svn: 225518
We forgot to mark designated initializer expression that contain type
dependent array designators as type dependent. This would lead to
crashes when we try to determine which array element we were trying to
initialize.
This fixes PR22056.
llvm-svn: 225494
we're instantiating, if there's a ParmVarDecl within a FunctionDecl context
that is not a parameter of that function. Add some asserts to catch this kind
of issue more generally, and fix another bug exposed by those asserts where we
were missing a local instantiation scope around substitution of
explicitly-specified template arguments.
llvm-svn: 225490
transform.
Also diagnose typos in the initializer of an invalid C++ declaration.
Both issues were hit using the same line of test code, depending on
whether the code was treated as C or C++.
Fixes PR22092.
llvm-svn: 225389
r185773 added an assert that checked that a CXXUnresolvedConstructExpr either
has a valid rparen, or exactly one argument. This doesn't have to be true for
invalid inputs. Convert the assert to an if, and add a test for this case.
Found by SLi's afl bot.
llvm-svn: 225140
Treat volatile accesses as "maybe" instead of "definite" side effects for the purposes of warning on evaluations in an unevaluated context. No longer diagnose on idiomatic code like:
int * volatile v;
(void)sizeof(*v);
llvm-svn: 225116
GCC permits array l-values in asm output operands even though they
aren't modifiable l-values. We used to permit it but this behavior
regressed in r224916.
llvm-svn: 224918
Functions are l-values in C++ but shouldn't be available as output
parameters in inline assembly. Neither should overloaded function
l-values.
This fixes PR21949.
llvm-svn: 224916
Clang has a hack to accept definitions of structs with tag names which
have the same name as intrinsics. However, this hack didn't guard
against annotation tokens showing up in the token stream.
llvm-svn: 224909
We expected the type of a TagDecl to be a TagType, not an
InjectedClassNameType. Introduced a helper method, Type::getAsTagDecl,
to abstract away the difference; redefine Type::getAsCXXRecordDecl to be
in terms of it.
llvm-svn: 224898
The lit.cfg files only add .cpp to suffixes, so these tests used to never run,
oops. (Also tweak to of these tests in minor ways to make the actually pass.)
llvm-svn: 224718
Previously we thought the instance member was a function, not a field,
and we'd say something silly like:
t.cpp:4:27: error: call to non-static member function without an object argument
static int f() { return n; }
^
Noticed in PR21923.
llvm-svn: 224480
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.
llvm-svn: 224471
pessimistic about when to do so.
This also fixes PR21905 as the initialization argument was no longer
viewed as being type dependent due to the TypoExpr being type-cast.
llvm-svn: 224386
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
llvm-svn: 224375
Turning our _Atomic L-value into an R-value removes its _Atomic-ness.
However, we didn't update our 'FromType' which made
ScalarTypeToBooleanCastKind think we were trying to pass it a
non-scalar.
This fixes PR21836.
llvm-svn: 224322
We know that const_cast<char *>((void)Something) is ill-formed, even if
'Something' is dependent because you can't cast from void to a pointer
type.
This fixes PR21845.
llvm-svn: 224299
Previously we would attempt to build a TypeSourceInfo for a null type,
and then we would forget to pop the function scope before returning an
error.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D6665
llvm-svn: 224271
Don't send a value dependent expression into the expression evaluator,
HandleSizeof would crash. Making HandleSizeof handle dependent types
would noisily warn about the operation even if everything turns out OK
after instantiation.
This fixes PR21848.
llvm-svn: 224240
clang lets programmers be pretty cavalier when it comes to void return
statements in functions which have non-void return types. However, we
cannot be so forgiving in constexpr functions: evaluation will go off
the rails very quickly.
Instead, keep the return statement in the AST but mark the function as
invalid. Doing so gives us nice diagnostics while making constexpr
evaluation halt.
This fixes PR21859.
llvm-svn: 224189
The extension has the following syntax:
__builtin_call_with_static_chain(Call, Chain)
where Call must be a function call expression and Chain must be of pointer type
This extension performs a function call Call with a static chain pointer
Chain passed to the callee in a designated register. This is useful for
calling foreign language functions whose ABI uses static chain pointers
(e.g. to implement closures).
Differential Revision: http://reviews.llvm.org/D6332
llvm-svn: 224167
having OptimizeNone remove them again, just don't add them in the
first place if the function already has OptimizeNone.
Note that MinSize can still appear due to attributes on different
declarations; a future patch will address that.
llvm-svn: 224047
Comparing the address of an object with an incomplete type might return
true with a 'distinct' object if the former has a size of zero.
However, such an object should compare unequal with null.
llvm-svn: 224040
getLVForNamespaceScopeDecl believed that it wasn't possible for it to
ever see an IndirectFieldDecl. However, this can occur when determining
whether or not something is a redeclaration of a member of an anonymous
static union.
This fixes PR21858.
llvm-svn: 223975
This attribute serves as a hint to improve warnings about the ranges of
enumerators used as flag types. It currently has no working C++ implementation
due to different semantics for enums in C++. For more explanation, see the docs
and testcases.
Reviewed by Aaron Ballman.
llvm-svn: 222906
GCC and ICC both reject this and the 'Runtime-sized arrays with
automatic storage duration' (N3639) paper forbade this as well.
Previously, we would crash on our way to mangling.
This fixes PR21632.
llvm-svn: 222569
Clang r181627 moved a check for block-scope variables into this code for
handling thread storage class specifiers, but in the process, it broke the
logic for checking if the target supports TLS. Fix this with some simple
restructuring of the code. rdar://problem/18796883
llvm-svn: 222512
for lambda expressions. That can't ever work; we need to transform the
parameters in order to create new ones in the new call operator context.
Fixes a rejects-valid when transforming a context containing a
lambda-expression that uses its function parameters in C++14 mode.
llvm-svn: 222482
std::X::swap exception specifications (allowing parsing of non-conforming code
in libstdc++). The old conditions also matched the functions in MSVC's STL,
which were relying on deferred parsing here.
llvm-svn: 222471
If there is more than one TypoExpr within the expr being transformed and
any but the last TypoExpr seen don't have any viable candidates, the
tree transform will be aborted early and the remaining TypoExprs are
never seen and hence never diagnosed. This adds a simple
RecursiveASTVisitor to find all of the TypoExprs to be diagnosed in the
case where typo correction of the entire expr fails (and the result of
the tree transform is an ExprError).
llvm-svn: 222465
Sema::ActOnIdExpression to use the new functionality.
Among other things, this allows recovery in several cases where it
wasn't possible before (e.g. correcting a mistyped static_cast<>).
llvm-svn: 222464
The bug is that ExprCleanupObjects isn't always empty
in a fresh evaluation context. New evaluation contexts just
track the current depth of the stack.
The assertion will misfire whenever we finish processing
a function body inside an expression that contained an earlier
block literal with non-trivial captures. That's actually
a lot less likely than you'd think, though, because it has
to be a real function declaration, not just another block.
Mixed block/lambda code would work, as would a template
instantiation or a local class definition.
The code works correctly if the assertion is disabled.
rdar://16356628
llvm-svn: 222194
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
llvm-svn: 222192
a member named 'swap' and then expect unqualified lookup for the name 'swap' in
its exception specification to find anything else.
Without delay-parsed exception specifications, this was ill-formed (NDR) by
[basic.scope.class]p1, rule 2. With delay-parsed exception specifications, the
call to 'swap' unambiguously finds the function being declared, which then
fails because the arguments don't work for that function.
llvm-svn: 221955
Without this, -Wunused-local-typedef would incorrectly warn on the two typedefs
in this program:
void foo() {
struct A {};
struct B : public A {
typedef A INHERITED;
B() : INHERITED() {}
typedef B SELF;
B(int) : SELF() {}
};
}
llvm-svn: 221765
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
Trying to import or export such classes doesn't make sense, and Clang
would assert trying to export vtables for them.
This is consistent with how we treat functions with internal linkage,
but it is stricter than MSVC so we may have to back down if it breaks
real code.
llvm-svn: 221160
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
llvm-svn: 221154
but MSABI was never defined in the test. It seems we are erroring
on code that we should be accepting when compiling for MSVC compatibility.
This should make the test less confusing until PR21406 is fixed.
llvm-svn: 220825
This includes adding the new TypoExpr-based lazy typo correction to
LookupMemberExprInRecord as an alternative to the existing eager typo
correction.
llvm-svn: 220698
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
If a templated class is not instantiated, then the AST for it could be missing
some things that would throw the field checker off. Wait until specialization
before emitting these warnings.
llvm-svn: 220363
complete object to a pointer to the start of another complete object does
not evaluate to the constant 'false'. All other comparisons between the
addresses of subobjects of distinct complete objects still do.
llvm-svn: 220343
A second instance of attributed types escaped the previous change, identified
thanks to Richard Smith! When deducing the void case, we would also assume that
the type would not be attributed. Furthermore, properly handle multiple
attributes being applied to a single TypeLoc.
Properly handle this case and future-proof a bit by ignoring parenthesis
further. The test cases do use the additional parenthesis to ensure that this
case remains properly handled.
Addresses post-commit review comments from Richard Smith to SVN r219851.
llvm-svn: 219974
Specifically, avoid typo-correcting the variable name into a type before
typo-correcting the actual type name in the declaration. Doing so
results in a very unpleasant cascade of errors, with the typo correction
of the actual type name being buried in the middle.
llvm-svn: 219732
and !=) to support mixed complex and real operand types.
This requires removing an assert from SemaChecking, and adding support
both to the constant evaluator and the code generator to synthesize the
imaginary part when needed. This seemed somewhat cleaner than having
just the comparison operators force real-to-complex conversions.
I've added test cases for these operations. I'm really terrified that
there were *no* tests in-tree which exercised this.
This turned up when trying to build R after my change to the complex
type lowering.
llvm-svn: 219570
operators where one type is a C complex type, and to emit both the
efficient and correct implementation for complex arithmetic according to
C11 Annex G using this extra information.
For both multiply and divide the old code was writing a long-hand
reduced version of the math without any of the special handling of inf
and NaN recommended by the standard here. Instead of putting more
complexity here, this change does what GCC does which is to emit
a libcall for the fully general case.
However, the old code also failed to do the proper minimization of the
set of operations when there was a mixed complex and real operation. In
those cases, C provides a spec for much more minimal operations that are
valid. Clang now emits the exact suggested operations. This change isn't
*just* about performance though, without minimizing these operations, we
again lose the correct handling of infinities and NaNs. It is critical
that this happen in the frontend based on assymetric type operands to
complex math operations.
The performance implications of this change aren't trivial either. I've
run a set of benchmarks in Eigen, an open source mathematics library
that makes heavy use of complex. While a few have slowed down due to the
libcall being introduce, most sped up and some by a huge amount: up to
100% and 140%.
In order to make all of this work, also match the algorithm in the
constant evaluator to the one in the runtime library. Currently it is
a broken port of the simplifications from C's Annex G to the long-hand
formulation of the algorithm.
Splitting this patch up is very hard because none of this works without
the AST change to preserve non-complex operands. Sorry for the enormous
change.
Follow-up changes will include support for sinking the libcalls onto
cold paths in common cases and fastmath improvements to allow more
aggressive backend folding.
Differential Revision: http://reviews.llvm.org/D5698
llvm-svn: 219557
Summary: This fixes PR21235.
Test Plan: Includes an automated test.
Reviewers: hansw
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5718
llvm-svn: 219551
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365
llvm-svn: 219393
Windows TLS relies on indexing through a tls_index in order to get at
the DLL's thread local variables. However, this index is not exported
along with the variable: it is assumed that all accesses to thread local
variables are inside the same module which created the variable in the
first place.
While there are several implementation techniques we could adopt to fix
this (notably, the Itanium ABI gets this for free), it is not worth the
heroics.
Instead, let's just ban this combination. We could revisit this in the
future if we need to.
This fixes PR21111.
llvm-svn: 219049
Richard noted in the review of r217349 that extra handling of
__builtin_assume_aligned inside of the expression evaluator was needed. He was
right, and this should address the concerns raised, namely:
1. The offset argument to __builtin_assume_aligned can have side effects, and
we need to make sure that all arguments are properly evaluated.
2. If the alignment assumption does not hold, that introduces undefined
behavior, and undefined behavior cannot appear inside a constexpr.
and hopefully the diagnostics produced are detailed enough to explain what is
going on.
llvm-svn: 218992
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
llvm-svn: 218969
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
llvm-svn: 218925
This adds support for the align_value attribute. This attribute is supported by
Intel's compiler (versions 14.0+), and several of my HPC users have requested
support in Clang. It specifies an alignment assumption on the values to which a
pointer points, and is used by numerical libraries to encourage efficient
generation of vector code.
Of course, we already have an aligned attribute that can specify enhanced
alignment for a type, so why is this additional attribute important? The
problem is that if you want to specify that an input array of T is, say,
64-byte aligned, you could try this:
typedef double aligned_double attribute((aligned(64)));
void foo(aligned_double *P) {
double x = P[0]; // This is fine.
double y = P[1]; // What alignment did those doubles have again?
}
the access here to P[1] causes problems. P was specified as a pointer to type
aligned_double, and any object of type aligned_double must be 64-byte aligned.
But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes
undefined behavior. Getting round this problem requires a lot of awkward
casting and hand-unrolling of loops, all of which is bad.
With the align_value attribute, we can accomplish what we'd like in a well
defined way:
typedef double *aligned_double_ptr attribute((align_value(64)));
void foo(aligned_double_ptr P) {
double x = P[0]; // This is fine.
double y = P[1]; // This is fine too.
}
This attribute does not create a new type (and so it not part of the type
system), and so will only "propagate" through templates, auto, etc. by
optimizer deduction after inlining. This seems consistent with Intel's
implementation (thanks to Alexey for confirming the various Intel-compiler
behaviors).
As a final note, I would have chosen to call this aligned_value, not
align_value, for better naming consistency with the aligned attribute, but I
think it would be more useful to users to adopt Intel's name.
llvm-svn: 218910
Clang warns (treated as error by default, but still ignored in system headers)
when passing non-POD arguments to variadic functions, and generates a trap
instruction to crash the program if that code is ever run.
Unfortunately, MSVC happily generates code for such calls without a warning,
and there is code in system headers that use it.
This makes Clang not insert the trap instruction when in -fms-compatibility
mode, while still generating the warning/error message.
Differential Revision: http://reviews.llvm.org/D5492
llvm-svn: 218640
In addition to __builtin_assume_aligned, GCC also supports an assume_aligned
attribute which specifies the alignment (and optional offset) of a function's
return value. Here we implement support for the assume_aligned attribute by making
use of the @llvm.assume intrinsic.
llvm-svn: 218500
we were failing to find that bit-field when performing integer promotions. This
brings us closer to following the standard, and closer to GCC.
In C, this change is technically a regression: we get bit-field promotions
completely wrong in C, promoting cases that are categorically not bit-field
designators. This change makes us do so slightly more consistently, though.
llvm-svn: 218428
A record which contains a flexible array member is itself a flexible
array member. A struct which contains such a record should also
consider itself to be a flexible array member.
llvm-svn: 218378
lists. Since the fields are inititalized one at a time, using a field with
lower index to initialize a higher indexed field should not be warned on.
llvm-svn: 218339
that function, and apart from being slow, this is unnecessary: ADL can trigger
instantiations that are not permitted here. The standard isn't *completely*
clear here, but this seems like the intent, and in any case this approach is
permitted by [temp.inst]p7.
llvm-svn: 218330
warns when a guarded variable is passed by reference as a function argument.
This is released as a separate warning flag, because it could potentially
break existing code that uses thread safety analysis.
llvm-svn: 218087
The reasoning is that this construct is accepted by all compilers and valid in
C++11, so it doesn't seem like a useful warning to have enabled by default.
Building with -pedantic, -Wbind-to-temporary-copy, or -Wc++98-compat still
shows the warning.
The motivation is that I built re2, and this was the only warning that was
emitted during the build. Both changing re2 to fix the warning and detecting
clang and suppressing the warning in re2's build seem inferior than just giving
the compiler a good default for this warning.
Also move the cxx98compat version of this warning to CXX98CompatPedantic, and
update tests accordingly.
llvm-svn: 218008
We would end up marking the vtable of the derived class as used for no
reason. Because the call itself is qualified, it is never virtual, and
the vtable of the derived class isn't helpful. We would end up rejecting
code that MSVC accepts for no benefit.
See http://crbug.com/413478
llvm-svn: 217910
constexpr function. Part of this fix is a tentative fix for an as-yet-unfiled
core issue (we're missing a prohibition against reading mutable members from
unions via a trivial constructor/assignment, since that doesn't perform an
lvalue-to-rvalue conversion on the members).
llvm-svn: 217852
In Parser::ParseCXXClassMemberDeclaration(), it was possible to change
isAccessDecl = NextToken().is(tok::kw_operator);
to
isAccessDecl = false;
and no tests would fail. Now there's coverage for this.
llvm-svn: 217519
This makes use of the recently-added @llvm.assume intrinsic to implement a
__builtin_assume(bool) intrinsic (to provide additional information to the
optimizer). This hooks up __assume in MS-compatibility mode to mirror
__builtin_assume (the semantics have been intentionally kept compatible), and
implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM
now contains special logic to deal with assumptions of this form.
llvm-svn: 217349
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
llvm-svn: 217298
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in the diagnostic: we cannot jump from
here to there. The notes explain nicely why not.
llvm-svn: 217293
Originally, self reference checking made a double pass over some expressions
to handle reference type checking. Now, allow HandleValue to also check
reference types, and fallback to Visit for unhandled expressions.
llvm-svn: 217203
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.
llvm-svn: 217197
Scoped lockable objects (mutex guards) are implemented as if it is a
lock itself that is acquired upon construction and unlocked upon
destruction. As it if course needs to be used to actually lock down
something else (a mutex), it keeps track of this knowledge through its
underlying mutex field in its FactEntry.
The problem with this approach is that this only allows us to lock down
a single mutex, so extend the code to use a vector of underlying
mutexes. This, however, makes the code a bit more complex than
necessary, so subclass FactEntry into LockableFactEntry and
ScopedLockableFactEntry and move all the logic that differs between
regular locks and scoped lockables into member functions.
llvm-svn: 217016
don't mark the field as initialized until the next initializer instead of
instantly. Since this checker is AST based, statements are processed in tree
order instead of following code flow. This can result in different warnings
from just reordering the code. Also changed to use one checker per constructor
instead of creating a new checker per field.
class T {
int x, y;
// Already warns
T(bool b) : x(!b ? (1 + y) : (y = 5)) {}
// New warning added here, previously (1 + y) comes after (y = 5) in the AST
// preventing the warning.
T(bool b) : x(b ? (y = 5) : (1 + y)) {}
};
llvm-svn: 216641
Fix r216438 to catch more complicated self-initialized in std::move. For
instance, "Foo f = std::move(cond ? OtherFoo : (UNUSED_VALUE, f));"
Make sure that BinaryConditionalOperator, ConditionalOperator, BinaryOperator
with comma operator, and OpaqueValueExpr perform the correct usage forwarding
across the three uninitialized value checkers.
llvm-svn: 216627
This shouldn't really be allowed, but it comes up in real code (see PR). As
long as the decl hasn't been used there's no technical difficulty in supporting
it, so downgrade the error to a warning.
Differential Revision: http://reviews.llvm.org/D5087
llvm-svn: 216619
the no-arguments case. Don't expand this to an __attribute__((nonnull(A, B,
C))) attribute, since that does the wrong thing for function templates and
varargs functions.
In passing, fix a grammar error in the diagnostic, a crash if
__attribute__((nonnull(N))) is applied to a varargs function,
a bug where the same null argument could be diagnosed multiple
times if there were multiple nonnull attributes referring to it,
and a bug where nonnull attributes would not be accumulated correctly
across redeclarations.
llvm-svn: 216520
We would previously assert (a decl cannot have two DLL attributes) on this code:
template <typename T> struct __declspec(dllimport) S { T f() { return T(); } };
template struct __declspec(dllexport) S<int>;
The problem was that when instantiating, we would take the attribute from the
template even if the instantiation itself already had an attribute.
Also, don't inherit DLL attributes from the template to its members before
instantiation, as the attribute may change.
I couldn't figure out what MinGW does here, so I'm leaving that open. At least
we're not asserting anymore.
llvm-svn: 216340
The situation it is warning about (see PR20725) is not very likely
to be a real problem, and it is unclear what action the user should take
if the warning does fire.
llvm-svn: 216283
Normally we mark all members of exported classes referenced to get them emitted.
However, MSVC doesn't do this for class templates that are implicitly specialized or
just have an explicit instantiation declaration. For such specializations, the members
are emitted when referenced.
The exception is the case when the dllexport attribute is propagated from a base class
to a base class template that doesn't have an explicit attribute: in this case all
methods of the base class template do get instantiated.
llvm-svn: 216145
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
-Wthread-safety umbrella flag, pending updates to documentation. The flag
works, but is likely to be confusing to existing users of -Wthread-safety.
llvm-svn: 215679
It doesn't really make sense to try and do stuff with #pragma init_seg
when targeting non-Microsoft platforms; notions like library vs user
initializers don't exist for other targets.
This fixes PR20639.
llvm-svn: 215618
it. Diagnose with recovery if it appears after a function parameter that was
obviously supposed to be a parameter pack. Otherwise, warn if it immediately
follows a function parameter pack, because the user most likely didn't intend
to write a parameter pack followed by a C-style varargs ellipsis.
This warning can be syntactically disabled by using ", ..." instead of "...".
llvm-svn: 215408
macro arguments.
Previously, these warnings skipped any code in a macro expansion. Preform an
additional check and warn when the expression and context locations are both
in the macro argument.
The most obvious case not caught is passing a pointer directly to a macro,
i.e 'assert(&array)' but 'assert(&array && "valid array")' is caught. This is
because macro arguments are not typed and the conversion happens inside the
macro.
llvm-svn: 215251
As we only create temp dtor decision branches when a temp dtor needs to
be run (as opposed to for each logical branch in the original
expression), we must include the information about all previous logical
branches when we annotate the temp dtor decision branch.
llvm-svn: 215188
MSVC doesn't decide what the inheritance model for a returned member
pointer *until* a call expression returns it.
This fixes PR20017.
llvm-svn: 215164
If the truth value of a LHS is known, we can build the knowledge whether
a temporary destructor is executed or not into the CFG. This is needed
by the return type analysis.
llvm-svn: 215118
Changes to the original patch:
- model the CFG for temporary destructors in conditional operators so that
the destructors of the true and false branch are always exclusive. This
is necessary because we must not have impossible paths for the path
based analysis to work.
- add multiple regression tests with ternary operators
Original description:
Fix modelling of non-lifetime-extended temporary destructors in the
analyzer.
Changes to the CFG:
When creating the CFG for temporary destructors, we create a structure
that mirrors the branch structure of the conditionally executed
temporary constructors in a full expression.
The branches we create use a CXXBindTemporaryExpr as terminator which
corresponds to the temporary constructor which must have been executed
to enter the destruction branch.
2. Changes to the Analyzer:
When we visit a CXXBindTemporaryExpr we mark the CXXBindTemporaryExpr as
executed in the state; when we reach a branch that contains the
corresponding CXXBindTemporaryExpr as terminator, we branch out
depending on whether the corresponding CXXBindTemporaryExpr was marked
as executed.
llvm-svn: 215096
This matches MSVC's logic, which seems to be that when the friend
declaration is qualified, it cannot be a declaration of a new symbol
and so the dll linkage doesn't change.
Differential Revision: http://reviews.llvm.org/D4764
llvm-svn: 214774
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.
llvm-svn: 214390
The new flag, WantFunctionLikeCasts, covers a subset of the keywords
covered by WantTypeSpecifiers that can be used in casts that look like
function calls, e.g. "return long(5);", while excluding the keywords
like "enum" and "const" that would be included when WantTypeSpecifiers
is true but cannot be used in something that looks like a function call.
llvm-svn: 214109
til::SExpr. This is a large patch, with many small changes to pretty printing
and expression lowering to make the new SExpr representation equivalent in
functionality to the old.
llvm-svn: 214089
lambda expressions (other than their capture initializers) nor blocks. Do walk
into default argument expressions and default initializer expressions.
These bugs were causing us to produce broken CFGs whenever a lambda expression
was used to initialize a libstdc++ std::function object!
llvm-svn: 214050
The class seems to have an invariant that Entries is non-empty if
Invalid is false. It appears this method was previously private, and
all internal uses checked Invalid. Now there is an external caller, so
check Invalid to avoid array OOB underflow.
Fixes PR20420.
llvm-svn: 213816
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.
llvm-svn: 213725
being declared, not at the end. When pretty-printing a non-type template
parameter, put the name of the parameter in the middle of the type, not at the
end.
llvm-svn: 213718
Windows ARM indicates __va_start as a variadic function. However, the function
itself is treated as having 4 formal arguments:
- (out) pointer to the va_list
- (in) address of the last named argument
- (in) slot size for the type of the last argument
- address of the last named argument
The last argument does not seem to have any bearing on codegen, and thus is not
explicitly type checked at this point.
Unlike the previous handling for __va_start, it does not currently validate if
the parameter is the last named parameter (it seems that MSVC currently accepts
this).
llvm-svn: 213595
If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.
This patch fixes PR20055.
Differential Revision: http://reviews.llvm.org/D4378
llvm-svn: 213594
Summary:
This pragma is very rare. We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.
If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it. Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors. We would have to teach LLVM to
lower prioritized global ctors on COFF as well.
This should let us compile some silly uses of this pragma in WebKit /
Blink.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4549
llvm-svn: 213593
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.
llvm-svn: 213443
-- 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.
llvm-svn: 213224
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.
llvm-svn: 213201
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
Recognize additional cases, when '::' is mistyped as ':'.
This is a fix to RP18587 - colons have too much protection in member-declarations
Review is tracked by http://reviews.llvm.org/D3653.
This is an attempt to recommit the fix, initially committed as r212957 but then
reverted in r212965 as it broke self-build. In the updated patch ParseDirectDeclarator
turns on colon protection in for context as well.
llvm-svn: 213120
Otherwise, multiple errors such as having unknown identifiers for two
arguments won't be diagnosed properly (e.g. only the first one would
have a diagnostic message if typo correction fails even though both
would be diagnosed if typo correction suggests a replacement).
llvm-svn: 213003
array prvalue), treat that as a direct binding. Only the class prvalue case
needs to be excluded here; the rest are extensions anyway, so we can treat them
as we would in C++11.
llvm-svn: 212978
We don't have a style guide for diagnostic messages, but convention strongly
favours the forms:
'attribute is not supported', 'unsupported attribute'
We generally avoid:
'attribute is unsupported', 'non-supported attribute'
llvm-svn: 212972
This reverts commit r212957. It broke the self-host on code like this
from LLVM's option library:
for (auto Arg: filtered(Id0, Id1, Id2))
llvm-svn: 212965
Recognize additional cases, when '::' is mistyped as ':'.
This is a fix to RP18587 - colons have too much protection in member-declarations.
Differential Revision: http://reviews.llvm.org/D3653
llvm-svn: 212957
a function pointer is neither better nor worse than binding a function lvalue
to a function rvalue reference. Don't get confused and think that both bindings
are binding to a function lvalue (which would make the lvalue form win); the
const reference is binding to an rvalue.
The "real" bug in PR20218 is still present: we're getting the wrong answer from
template argument deduction, and that's what leads us to this weird overload
set.
llvm-svn: 212916
The relevant portion of C++ standard says [namespace.memdef]p3:
If the name in a friend declaration is neither qualified nor a
template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity
has been previously declared shall not consider any scopes outside the
innermost enclosing namespace.
MSVC does not implement that rule for types. If there is a type in an
enclosing namespace, they consider an unqualified tag declaration with
the same name to be a redeclaration of the type from another namespace.
Implementing compatibility is a simple matter of disabling our
implementation of this rule for types, which was added in r177473.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4443
llvm-svn: 212784
Give scope a SEHTryScope bit, set that in ParseSEHTry(), and let Sema
walk the scope chain to find the SEHTry parent on __leave statements.
(They are rare enough that it seems better to do the walk instead of
giving Scope a SEHTryParent pointer -- this is similar to AtCatchScope.)
llvm-svn: 212422
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.
llvm-svn: 212238
Fixes PR20110, where Clang hits an assertion failure when it expects that the
sub-expression of a bit cast to pointer to also be a pointer, but gets a value
instead.
Differential Revision: http://reviews.llvm.org/D4280
llvm-svn: 212160
Previously dllimport variables inside of template arguments relied on
not using the C++11 codepath when -fms-compatibility was set.
While this allowed us to achieve compatibility with MSVC, it did so at
the expense of MingW.
Instead, try to use the DeclRefExpr we dig out of the template argument.
If it has the dllimport attribute, accept it and skip the C++11
null-pointer check.
llvm-svn: 211766
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
Consider the following code:
template <typename T> class Base {};
class __declspec(dllexport) class Derived : public Base<int> {}
When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.
This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.
MinGW doesn't do this kind of propagation.
Differential Revision: http://reviews.llvm.org/D4264
llvm-svn: 211725
Types defined in function prototype are diagnosed earlier in C++ compilation.
They are put into declaration context where the prototype is introduced. Later on,
when FunctionDecl object is created, these types are moved into the function context.
This patch fixes PR19018 and PR18963.
Differential Revision: http://reviews.llvm.org/D4145
llvm-svn: 211718
The C++ language requires that the address of a function be the same
across all translation units. To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule. MSVC
implements this by dynamically querying the import address table located
in the linked executable. This means that the address of such a
function in C++ is not constant (which violates other rules).
However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever. This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table. The effect this has is, to say the
least, perplexing.
Consider the following C program:
__declspec(dllimport) void f(void);
typedef void (*fp)(void);
static const fp var = &f;
const fp fun() { return &f; }
int main() { return fun() == var; }
MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!
Note that LLVM's optimizers are strong enough to figure out that "main"
should return true. However, this result is dependent on having
optimizations enabled!
N.B. This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose. Add tests to make sure we don't regress here.
llvm-svn: 211677
The address of dllimport functions can be accessed one of two ways:
- Through the IAT which is symbolically referred to with a symbol
starting with __imp_.
- Via the wrapper-function which ends up calling through the __imp_
symbol.
The problem with using the wrapper-function is that it's address will
not compare as equal in all translation units. Specifically, it will
compare unequally with the translation unit which defines the function.
This fixes PR19955.
llvm-svn: 211570
The address of dllimport variables isn't something that can be
meaningfully used in a constexpr context and isn't suitable for
evaluation at load-time. They require loads from memory to properly
evaluate.
This fixes PR19955.
Differential Revision: http://reviews.llvm.org/D4250
llvm-svn: 211568
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
CL permits static redeclarations to follow extern declarations. The
storage specifier on the latter declaration has no effect.
This fixes PR20034.
Differential Revision: http://reviews.llvm.org/D4149
llvm-svn: 211238
Previously we would do the access check from the context of
MarkVTableUsed.
Also update this test to C++11, since that is typically used with the MS
C++ ABI.
Fixes PR20005.
llvm-svn: 210850
The only external/visible functional change that fell out of this
refactoring is that there was one less case where the typo caching
and/or counting didn't work properly. The result is that a test case
had to be moved from typo-correction.cpp to typo-correction-pt2.cpp
to avoid the hard-coded limit on per file/TU typo correction attempts.
llvm-svn: 210669
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
We would previously end up with an error when instantiating the
following template:
template <typename> struct __declspec(dllimport) S {
void foo() = delete;
};
S<int> s;
error: attribute 'dllimport' cannot be applied to a deleted function
llvm-svn: 210550
David Majnemer