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
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
Libraries specify enabled/disabled features using macro defs of 0/1, in such cases the -Wconstant-logical-operand
is noise.
rdar://15410291
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207386 91177308-0d34-0410-b5e6-96231b3b80d8
switch CurContext due to class template instantiation.
Fixes crash of the included test case.
rdar://16527205
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207325 91177308-0d34-0410-b5e6-96231b3b80d8
obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205653 91177308-0d34-0410-b5e6-96231b3b80d8
If there are any scope specifiers, then a base class must be named or
the symbol isn't from a base class.
Fixes PR19233.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204753 91177308-0d34-0410-b5e6-96231b3b80d8
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203974 91177308-0d34-0410-b5e6-96231b3b80d8
getTypeSize (which rounds up sizes) in order to issue diagnostics
when casting to mismatched vector sizes; instead of crashing in IRGen.
// rdar:// 16196902. Reviewed offline by John McCall.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203175 91177308-0d34-0410-b5e6-96231b3b80d8
const char *format = "%s";
std::experimental::string_view view = "foo";
printf(format, view);
In this case, not only warn about a class type being used here, but also suggest that calling c_str() might be a good idea.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202461 91177308-0d34-0410-b5e6-96231b3b80d8
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202216 91177308-0d34-0410-b5e6-96231b3b80d8
When a lax conversion featured a vector and a non-vector, we were
only requiring the non-vector to be a scalar type, but really it
needs to be a real type (i.e. integral or real floating); it is
not reasonable to allow a pointer, member pointer, or complex
type here.
r198474 required lax conversions to match in "data size", i.e.
element size * element count, forbidding matches that happen
only because a vector is rounded up to the nearest power of two
in size. Unfortunately, the erroneous logic was repeated in
several different places; unify them to use the new condition,
so that it triggers for arbitrary conversions and not just
those performed as part of binary operator checking.
rdar://15931426
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200810 91177308-0d34-0410-b5e6-96231b3b80d8
case when correcting for too many arguments (r191450 had only fixed the
problem for when there were too few arguments). Also fix the underlining
for both cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200268 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
the program, in C++. (We allow the latter as an extension, since we've always
permitted it, and GCC does the same, and our supported C++ ABIs don't do
anything special in main.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199782 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r199475 (which reverted r199416) with fixes for the
breakages.
We wouldn't lock an inheritance model if we saw a pointer-to-member
formed as a result of the address-of operator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199482 91177308-0d34-0410-b5e6-96231b3b80d8
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199209 91177308-0d34-0410-b5e6-96231b3b80d8
consideration the num-of-elements*width-of-element width.
Disallow casts when such width is not equal between the vector types otherwise
we may end up with an invalid LLVM bitcast.
rdar://15722308.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198474 91177308-0d34-0410-b5e6-96231b3b80d8
- Remove the additions to ObjCMethodDecl & ObjCIVarDecl that were getting de/serialized and consolidate
all functionality for the checking for this warning in Sema::DiagnoseUnusedBackingIvarInAccessor
- Don't check immediately after the method body is finished, check when the @implementation is finished.
This is so we can see if the ivar was referenced by any other method, even if the method was defined after the accessor.
- Don't silence the warning if any method is called from the accessor silence it if the accessor delegates to another method via self.
rdar://15727325
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198432 91177308-0d34-0410-b5e6-96231b3b80d8
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198271 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.
This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings. By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent. It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.
This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated". It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
(e.g., "function" instead of "destructor"). By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away. This diagnostic can likely be further wordsmithed
to be shorter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197627 91177308-0d34-0410-b5e6-96231b3b80d8
The problem here is more serious than the fix implies. Adding a field
to a class updates the triviality bits for the class (among other
things). Failing to require a complete type before adding the field
meant that these updates don't happen in the well-formed case where
the capture is an uninstantiated class template specialization,
leading the lambda itself to be treated as having a trivial copy
constructor when it shouldn't. Fixes <rdar://problem/15560464>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197623 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
when diagnosing casting of a cstring literal to
NSString in default and -fobjc-arc mode.
// rdar://14106083
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197515 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
With the introduction of explicit address space casts into LLVM, there's
a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA
and code to produce address space casts from those kinds when appropriate.
Patch by Michele Scandale!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197036 91177308-0d34-0410-b5e6-96231b3b80d8
more than one such initializer in a union, make mem-initializers override
default initializers for other union members, handle anonymous unions with
anonymous struct members better. Fix a couple of semi-related bugs exposed by
the tests for same.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196892 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
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
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195814 91177308-0d34-0410-b5e6-96231b3b80d8
expression that is not a zero literal, in C. This is a different, and more
targeted, approach than that in r194540.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195303 91177308-0d34-0410-b5e6-96231b3b80d8
- If a deprecated class refers to another deprecated class, do not warn.
- @implementations of a deprecated class can refer to other deprecated things.
Fixes <rdar://problem/15407366> and <rdar://problem/15466783>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195259 91177308-0d34-0410-b5e6-96231b3b80d8
Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.
What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.
As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.
Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.
Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming.
This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
- generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
- nested variadic expansions such as:
auto K = [](auto ... OuterArgs) {
vp([=](auto ... Is) {
decltype(OuterArgs) OA = OuterArgs;
return 0;
}(5)...);
return 0;
};
auto M = K('a', ' ', 1, " -- ", 3.14);
currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.
A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!
Now let's hope this commit doesn't upset the buildbot gods ;)
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194188 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__. This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.
Reviewers: rnk, rsmith, thakis
CC: cfe-commits, silvas
Differential Revision: http://llvm-reviews.chandlerc.com/D2109
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194181 91177308-0d34-0410-b5e6-96231b3b80d8
specializations. Also switch to -Wuninitialized for a test case that depended
on a warning firing in template specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193906 91177308-0d34-0410-b5e6-96231b3b80d8
-fobjc-subscripting-legacy-runtime which is off
by default and on only when using ObjectiveC
legacy runtime. Use this flag to allow
array and dictionary subscripting and disallow
objectiveC pointer arithmatic in ObjectiveC
legacy runtime. // rdar://15363492
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193889 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, this warns when a character literal is added (using '+') to a
variable with type 'char *' (or any other pointer to character type). Like
-Wstring-plus-int, there is a fix-it to change "foo + 'a'" to "&foo['a']"
iff the character literal is on the right side of the string.
Patch by Anders Rönnholm!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193418 91177308-0d34-0410-b5e6-96231b3b80d8
We would previously not diagnose this which would lead to crashes (on
very strange code).
This fixes PR17675.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193397 91177308-0d34-0410-b5e6-96231b3b80d8
Commit r191484 treated constexpr function templates as normal function
templates with respect to delaying their parsing. However, this is
unnecessarily restrictive because there is no compatibility concern with
constexpr, MSVC doesn't support it.
Instead, simply disable delayed template parsing for constexpr function
templates. This largely reverts the changes made in r191484 but keeps
it's unit test.
This fixes PR17661.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193274 91177308-0d34-0410-b5e6-96231b3b80d8
If unqualified id lookup fails while parsing a class template with a
dependent base, clang with -fms-compatibility will pretend the user
prefixed the name with 'this->' in order to delay the lookup. However,
if there was a unary ampersand, Sema::ActOnDependentIdExpression() will
create a DependentDeclRefExpr, which is not what we wanted at all. Fix
this by building the CXXDependentScopeMemberExpr directly instead.
In order to be fully MSVC compatible, we would have to defer all
attempts at name lookup to instantiation time. However, until we have
real problems with system headers that can't be parsed, we'll put off
implementing that.
Fixes PR16014.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1892
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192727 91177308-0d34-0410-b5e6-96231b3b80d8
The bool conversion operator on InstantiatingTemplate never added value and
only served to obfuscate the template instantiation routines.
This replaces the conversion and its callers with an explicit isInvalid()
function to make it clear what's going on at a glance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192177 91177308-0d34-0410-b5e6-96231b3b80d8
extension. The GCC folks have decided to support this even though the standard
committee have not yet approved this feature.
Patch by Hristo Venev!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192128 91177308-0d34-0410-b5e6-96231b3b80d8
In chicago, Doug had requested that I go ahead and commit the refactor as a separate change, if all the tests passed.
Lets hope the buildbots stay quiet.
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192087 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, IR generation can't handle file-scope compound literals with
non-constant initializers in C++.
Fixes PR17415 (the first crash in the bug).
(We should probably change (T){1,2,3} to use the same codepath as T{1,2,3} in
C++ eventually, given that the semantics of the latter are actually defined by
the standard.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191719 91177308-0d34-0410-b5e6-96231b3b80d8
putting them in the call operator's DeclContext. This better matches the
language wording and avoids some cases where code gets confused by them for
namespace-scope lambdas and the like.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191606 91177308-0d34-0410-b5e6-96231b3b80d8
Functions declared as constexpr must have their parsing delayed in
-fdelayed-template-parsing mode so as not to upset later template
instantiation.
N.B. My reading of the standard makes it seem like delayed template
parsing is at odds with constexpr. We may want to make refinements in
other places in clang to make constexpr play nicer with this feature.
This fixes PR17334.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191484 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed the wrong text was being replaced with the correction while
working on expanding the "namespace-aware" typo correction to include
classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191450 91177308-0d34-0410-b5e6-96231b3b80d8
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191064 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190915 91177308-0d34-0410-b5e6-96231b3b80d8
This expands very slightly what -Wtautological-compare considers to be
tautological to include implicit accesses to C++ fields and ObjC ivars.
I don't want to turn this into a full expression-identity check, but
these additions seem pretty well-contained, and maintain the theme
of checking for "x == x".
<rdar://problem/14431127>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190118 91177308-0d34-0410-b5e6-96231b3b80d8
When an AST file is built based on another AST file, it can use a decl from
the fist file, and therefore mark the "isUsed" bit. We need to note this in
the AST file so that the bit is set correctly when the second AST file is
loaded.
This patch introduces the distinction between setIsUsed() and markUsed() so
that we don't call into the ASTMutationListener callback when it wouldn't
be appropriate.
Fixes PR16635.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190016 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian