In particular, remove the OpaqueExpr transformation from r225389 and
move the correction of the conditional from CheckConditionalOperands to
ActOnConditionalOp before the OpaqueExpr is created. This fixes the
typo correction behavior in C code that uses the GNU extension for a
binary ?: (without an expression between the "?" and the ":").
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227220 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
Move the logic for checking self moves into SemaChecking and add that function
to Sema since it is now used in multiple places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225756 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225581 91177308-0d34-0410-b5e6-96231b3b80d8
Parser::ParseNamespace can get a little confused when it found itself
inside a compound statement inside of a non-static data member
initializer.
Try to determine that the statement expression's scope makes sense
before trying to parse it's contents.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225514 91177308-0d34-0410-b5e6-96231b3b80d8
In SemaCUDA all implicit functions were considered host device, this led to
errors such as the following code snippet failing to compile:
struct Copyable {
const Copyable& operator=(const Copyable& x) { return *this; }
};
struct Simple {
Copyable b;
};
void foo() {
Simple a, b;
a = b;
}
Above the implicit copy assignment operator was inferred as host device but
there was only a host assignment copy defined which is an error in device
compilation mode.
Differential Revision: http://reviews.llvm.org/D6565
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224358 91177308-0d34-0410-b5e6-96231b3b80d8
Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments.
No functional changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224329 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, if global variable is marked as a private OpenMP variable, the compiler crashes in debug version or generates incorrect code in release version. It happens because in the OpenMP region the original global variable is used instead of the generated private copy. It happens because currently globals variables are not captured in the OpenMP region.
This patch adds capturing of global variables iff private copy of the global variable must be used in the OpenMP region.
Differential Revision: http://reviews.llvm.org/D6259
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224323 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224240 91177308-0d34-0410-b5e6-96231b3b80d8
OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces:
- the named address spaces (__global, __local, and __private) => __generic - implicitly converted;
- __generic => named - with an explicit cast;
- named <=> named - disallowed;
- __constant <=> any other - disallowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222834 91177308-0d34-0410-b5e6-96231b3b80d8
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<>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222464 91177308-0d34-0410-b5e6-96231b3b80d8
nonnull attribute when comparison is always true/false.
Original patch by Steven Wu. I have added extra code to prevent issuing of
warning when the nonnull parameter is modified prior to the comparison.
This addition prevents false positives in the most obvious cases.
There may still be false positive warnings in some cases (as one of my tests
indicates), but benefit far outweighs such cases. rdar://18712242
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222264 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Ok, here is somewhat addition to D6217 aiming to preserve old darwin behavior wrt the typedefed types. The actual change to SemaChecking turned out to be pretty gross, in particular:
1. We need to extract the typedef'ed type for proper diagnostics
2. We need to walk over paren expressions as well
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6256
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222044 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Consider the following nifty 1 liner: (0 ? csqrtl(2.0f) : sqrtl(2.0f)). One can easily obtain such code from e.g. tgmath. Right now it produces an assertion because we fail to do the promotion real => _Complex real.
The case was properly handled previously (old handleOtherComplexFloatConversion routine), but was forgotten in the current version. This seems to be about fallout from r219557
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6217
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221821 91177308-0d34-0410-b5e6-96231b3b80d8
code for calling CorrectTypo.
Includes a needed fix for non-C++ code to not choke on TypoExprs (which
also resolves a TODO from r220698).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221736 91177308-0d34-0410-b5e6-96231b3b80d8
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
(patch reapplied after lldb issue was fixed in r221660).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221691 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221573 91177308-0d34-0410-b5e6-96231b3b80d8
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
John McCall, please review post-commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221404 91177308-0d34-0410-b5e6-96231b3b80d8
An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas.
This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP.
Differential Revision: http://reviews.llvm.org/D5099
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220850 91177308-0d34-0410-b5e6-96231b3b80d8
Part of the infrastructure is a map from a TypoExpr to the Sema-specific
state needed to correct it, along with helpers to ease dealing with the
state.
The the typo count is propagated up the stack of
ExpressionEvaluationContextRecords when one is popped off of to
avoid accidentally dropping TypoExprs on the floor. For example,
the attempted correction of g() in test/CXX/class/class.mem/p5-0x.cpp
happens with an ExpressionEvaluationContextRecord that is popped off
the stack prior to ActOnFinishFullExpr being called and the tree
transform for TypoExprs being run.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220695 91177308-0d34-0410-b5e6-96231b3b80d8
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219589 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219557 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218640 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218330 91177308-0d34-0410-b5e6-96231b3b80d8
__builtin___memcpy_chk and similar builtins are
being used. Patch by Jacques Fortier (with added
clang tests). rdar://11076881
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218063 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217910 91177308-0d34-0410-b5e6-96231b3b80d8
In line with SemaOpenMP.cpp, etc. CUDA-specific semantic analysis code goes into
a separate file. This is in anticipation of adding extra functionality here in
the near future.
No change in functionality.
Review: http://reviews.llvm.org/D5160
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217043 91177308-0d34-0410-b5e6-96231b3b80d8
In C++11, instantiation of exception specs is deferred. The instantiation is
done in MarkFunctionReferenced(), which wasn't called for non-OdrUsed functions,
which then caused an assert in codegen. Fixes PR19190, see the bug for details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216562 91177308-0d34-0410-b5e6-96231b3b80d8
The code used getLocStart() instead of getLocEnd(). This works for single
token expressions, but breaks if the expression is longer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216306 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
Clang forgot that '++s.m' was a bitfield l-value and permit it's address
to be taken; this would crash at CodeGen-time.
Instead, propagate the object-kind when we see the prefix
increment/decrement.
This fixes PR20496.
Differential Revision: http://reviews.llvm.org/D4733
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214386 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
This fixes compilation errors about incomplete types used with WebKit's
RefPtr template. Simply calling an out of line constructor should not
instantiate all inline and defaulted virtual methods.
Tested by building and testing several big piles of code on Linux.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4429
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213109 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC accepts __noop without any trailing parens and treats it like a
literal zero. We don't treat __noop as an integer literal, but now at
least we can parse a naked __noop expression.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4476
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212860 91177308-0d34-0410-b5e6-96231b3b80d8
when casting a retainable object to a objc_bridge_related
CF type with the suggestion of applying the method
specified in the bridging attribute to the object.
// rdar://15932435
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211807 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211441 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211434 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211426 91177308-0d34-0410-b5e6-96231b3b80d8
a qualified-id type because pointer is object of a forward
class declaration, include this info in a diagnostic note.
// rdar://10751015
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211324 91177308-0d34-0410-b5e6-96231b3b80d8
retainable ObjC pointers without requiring a bridge-cast
in the context of pointer comparison as this is in effect
a +0 context. // rdar://16627903
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211243 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
Summary:
'sizeof' is a UnaryExprOrTypeTrait, and it can contain either a type or
an expression. This change threads a RecoveryTSI parameter through the
layers between TransformUnaryExprOrTypeTrait the point at which we look
up the type. If lookup finds a single type result after instantiation,
we now build TypeSourceInfo for it just like a normal transformation
would.
This fixes the last error in the hello world ATL app that I've been
working with, and it now links and runs with clang. Please try it and
file bugs!
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4108
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210855 91177308-0d34-0410-b5e6-96231b3b80d8
I wasn't able to figure out how to emit this diagnostic from a SFINAE
context, so I don't have a test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210713 91177308-0d34-0410-b5e6-96231b3b80d8
We currently allow unqualified lookup for instance methods but not
static methods because we can't recover with a semantic 'this->'
insertion.
ATL headers have static methods that do unqualified lookup into
dependent base classes. The pattern looks like:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Bar; }
};
Now we recover as if the user had written:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Foo::Bar; }
};
... which will eventually look up Bar in T at instantiation time.
Now we emit a diagnostic in both cases, and delay lookup in other
contexts where 'this' is available and refers to a class with dependent
bases.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4079
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210611 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210608 91177308-0d34-0410-b5e6-96231b3b80d8
While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename. Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4049
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210607 91177308-0d34-0410-b5e6-96231b3b80d8
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209908 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
caused us to perform copy-initialization for the parameters of an allocation
function called by a new-expression multiple times, resulting in us rejecting
allocations that passed non-copyable parameters (and much worse things in
MSVC compat mode, where we potentially called this function multiple times).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208724 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us diagnose and perform more complete semantic analysis when faced
with errors in the function body or declaration.
By recovering here we provide more consistent diagnostics, particularly during
interactive editing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208394 91177308-0d34-0410-b5e6-96231b3b80d8
C++. This seems like a pointless (and indeed harmful) restriction to me, so
I've suggested removing it to -core and disabled this diagnostic by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208254 91177308-0d34-0410-b5e6-96231b3b80d8
Kaelyn Takata