a previously-computed linkage as an unsupportable error condition.
Per discussion on cfe-commits, this appears to be a
difficult-to-resolve flaw in our implementation approach;
we may pursue this as a language defect, but for now it's
better to diagnose it as unsupported than to produce
inconsistent results (or assertions). Anything that we can
do to limit how often this diagnostic fires, such as the
changes in r200380, is probably for the best, though.
llvm-svn: 200438
We would previously allow inappropriate inheritance keywords to appear
on class declarations. We would also allow inheritance keywords on
templates which were not fully specialized; this was divergent from
MSVC.
Differential Revision: http://llvm-reviews.chandlerc.com/D2585
llvm-svn: 200423
the linkage cache) when type-checking static local
variables.
There's a very deep problem here where the linkage of
a declaration can suddenly massively change as soon as
it's given a typedef name; these fixes, while optimizations
in their own right, are really just targeted workarounds.
rdar://15928125
llvm-svn: 200380
initialized from a constant expression in C++98, it can be used in
constant expressions, even if it was brace-initialized. Patch by
Rahul Jain!
llvm-svn: 200098
Previously, string literals were ignored in all logical expressions. This
reduces it to only ignore in logical and expressions.
assert(0 && "error"); // No warning
assert(0 || "error"); // Warn
Fixes PR17565
llvm-svn: 200056
override for the type of 'this', also clear it out (unless we're entering the
context of a lambda-expression, where it should be inherited).
llvm-svn: 199962
language options. This is not really ideal -- we should require the right
language options to be passed in, or not require language options to format a
name -- but it fixes a number of *obviously* wrong formattings. Patch by
Olivier Goffart!
llvm-svn: 199778
Checking in ActOnVariableDeclarator computes and caches the linkage using
the non-deduced auto type which defaults to external linkage. Depending on
how the auto type is deduced linkage can change and conflict with the
cached linkage, hitting asserts.
llvm-svn: 199774
Implement type trait primitives used in the latest edition of the Microsoft
standard C++ library type_traits header.
With this change we can parse much of the Visual Studio 2013 standard headers,
particularly anything that includes <type_traits>.
Fully implemented, available in all language modes:
* __is_constructible()
* __is_nothrow_constructible()
* __is_nothrow_assignable()
Partially implemented, semantic analysis WIP, available as MS extensions:
* __is_destructible()
* __is_nothrow_destructible()
llvm-svn: 199619
Check all default ctors, not just the first one we see. This brings
__has_nothrow_constructor() in line with the other unary type traits.
A C++ class can have multiple default constructors but clang was only checking
the first one written, presumably due to ambiguity in the GNU specification.
MSVC has the same bug, while g++ has the correct implementation which we now
match.
llvm-svn: 199618
String literal to char* conversion is deprecated in C++03, and is removed in
C++11. We still accept this conversion in C++11 mode as an extension, if we find
it in the best viable function.
llvm-svn: 199513
handling C++11 default initializers. Without this, other parts of Sema (such as
lambda capture) would think the default initializer is part of the surrounding
function scope.
llvm-svn: 199453
pointer, since this invokes undefined behavior. Based on a patch by Artyom
Skrobov! Handling of dependent exception specifications and some additional
testcases by me.
llvm-svn: 199452
attribute syntax. There's nothing generalized about this; it's one of
several first-class attribute syntaxes we support, all of which are
more-or-less equally general.
As discussed on cfe-commits, we may want to revisit this if we start allowing
this syntax as an extension in C (or if C adopts the syntax), but hopefully
this diagnostic wording will be crystal clear to everyone in the mean time.
llvm-svn: 199443
The MSVC ABI is rather finicky about the exact representation of it's
pointer-to-member representation. The exact position of when and where
it will go with one representation versus another appears to be when it
desires the pointer-to-member to be complete.
To properly implement this in clang, do several things:
- Give up on tracking the polymorphic nature of the class. It isn't
useful to Sema and is only pertinent when choosing CodeGen-time
details like whether the field-offset can be 0 instead of -1.
- Insist on locking-in the inheritance model when we ask our
pointer-to-member type to be complete. From there, grab the
underlying CXXRecordDecl and try to make *that* complete. Once we've
done this, we can calculate it's inheritance model and apply it using
an attribute.
N.B. My first bullet point is a lie. We will eventually care about the
specifics of whether or not a CXXRecordDecl is or is not polymorphic
because MSVC compatible mangling of such things depends on it. However,
I believe we will handle this in a rather different way.
llvm-svn: 199416
We would attempt to determine the inheritance relationship between
classes 'A' and 'B' during static_cast if we tried to convert from 'int
A::*' to 'int B::*'. However, the question "does A derive from B" is
not meaningful when 'A' isn't defined.
Handle this case by requiring that 'A' be defined.
This fixes PR18506.
llvm-svn: 199374
Changes made in r192200 fixed PR16992, which requested fixit suggesting
parenthesis if sizeof is followed by type-id. However expression in form
T() followed by ')' was incorrectly considered as a type-id if 'T' is
typedef name. This change fixes this case.
Differential Revision: http://llvm-reviews.chandlerc.com/D2440
llvm-svn: 199284
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
MSVC defines size_t without any explicit declarations. This change
allows us to be compatible with TUs that depend on this declaration
appearing from nowhere.
llvm-svn: 199190
consumable objects. These are useful for implementing error codes that
must be checked. Patch also includes some significant refactoring, which was
necesary to implement the new behavior.
llvm-svn: 199169
In preparation for making the Win32 triple imply MS ABI mode,
make all tests pass in this mode, or make them use the Itanium
mode explicitly.
Differential Revision: http://llvm-reviews.chandlerc.com/D2401
llvm-svn: 199130
The ABI requires the destructor to be invoked in the callee, but the
standard does not require access checks here so we avoid doing direct
access checks on the destructor.
If we end up needing to define an implicit destructor, we don't skip
access checks for the base class, etc. Those checks are effectively part
of generating the destructor definition, and aren't affected by which TU
the check is performed in.
Differential Revision: http://llvm-reviews.chandlerc.com/D2409
llvm-svn: 199120
Various attribute flavours are supported in C++98. Make it clear that this
compatibility warning relates specifically to C++11-style generalized
attributes.
llvm-svn: 199053
rules: instead of requiring flexible array members to be POD, require them to
be trivially-destructible. This seems to be the only constraint that actually
matters here (and even then, it's questionable whether this matters).
llvm-svn: 198983
issue 1430. Don't allow a pack expansion to be used as an argument to an alias
template unless the corresponding parameter is a parameter pack.
llvm-svn: 198833
type-specifier in C++. Some checks will assert in this case otherwise (in
particular, the access specifier may be missing if this happens inside a class
definition, due to a violation of an AST invariant).
llvm-svn: 198721
In all three checks, the note indicates a previous declaration and never a 'use'.
Before:
enum-scoped.cpp:92:6: note: previous use is here
enum Redeclare6 : int;
^
After:
enum-scoped.cpp:92:6: note: previous declaration is here
enum Redeclare6 : int;
^
llvm-svn: 198600
It was previously enabled in both but should only have been part of the drop-in
quirks mode that is 'MicrosoftMode' given that it's only useful for
compatibility with the Microsoft headers/runtime.
llvm-svn: 198548
Thisadds a new warning that warns on code like this:
if (memcmp(a, b, sizeof(a) != 0))
The warning looks like:
test4.cc:5:30: warning: size argument in 'memcmp' call is a comparison [-Wmemsize-comparison]
if (memcmp(a, b, sizeof(a) != 0))
~~~~~~~~~~^~~~
test4.cc:5:7: note: did you mean to compare the result of 'memcmp' instead?
if (memcmp(a, b, sizeof(a) != 0))
^ ~
)
test4.cc:5:20: note: explicitly cast the argument to size_t to silence this warning
if (memcmp(a, b, sizeof(a) != 0))
^
(size_t)( )
1 warning generated.
This found 2 bugs in chromium and has 0 false positives on both chromium and
llvm.
The idea of triggering this warning on a binop in the size argument is due to
rnk.
llvm-svn: 198063
Even g++ considers this a valid C++ identifier and it should only have been
visible in C mode.
Also drop the associated low-value diagnostic.
llvm-svn: 197995
This new warning detects when a function will recursively call itself on every
code path though that function. This catches simple recursive cases such as:
void foo() {
foo();
}
As well as more complex functions like:
void bar() {
if (test()) {
bar();
return;
} else {
bar();
}
return;
}
This warning uses the CFG. As with other CFG-based warnings, this is off
by default. Due to false positives, this warning is also disabled for
templated functions.
llvm-svn: 197853
Without this patch, record decls with invalid out-of-line method delcs would
sometimes be marked invalid, but not always. With this patch, they are
consistently never marked invalid.
(The code to do this was added in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100809/033154.html
, but the test from that revision is still passing.)
As far as I can tell, this was the only place where a class was marked invalid
after its definition was complete.
llvm-svn: 197848
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.
llvm-svn: 197627
We would previously emit redundant diagnostics for the following code:
struct S {
virtual ~S() = delete;
void operator delete(void*, int);
void operator delete(void*, double);
} s;
First we would check on ~S() and error about the ambigous delete functions,
and then we would error about using the deleted destructor.
If the destructor is deleted, there's no need to check it.
Also, move the check from Sema::ActOnFields to CheckCompleteCXXClass. These
are run at almost the same time, called from ActOnFinishCXXMemberSpecification.
However, CHeckCompleteCXXClass may mark a defaulted destructor as deleted, and
if that's the case we don't want to check it.
Differential Revision: http://llvm-reviews.chandlerc.com/D2421
llvm-svn: 197509
to determine if a move function is the std::move function. This allows functions
like std::__1::move to also be treated a the move function.
llvm-svn: 197445
CXXScopeSpec when necessary while performing typo correction. This fixes
the crash reported in PR18213 (the problem existed since r185487, and
r193020 made it easier to hit).
llvm-svn: 197409
This patch was submitted to the list for review and didn't receive a LGTM.
(In fact one explicit objection and one query were raised.)
This reverts commit r197295.
llvm-svn: 197299
The tests were perhaps made too relaxed in r197164 when we switched to the new
MinGW ABI. This makes sure we check explicitly for an optional thiscall
attribute and nothing else.
We should still look into whether we should print these attributes at all in
these cases.
llvm-svn: 197252
declarations that might lifetime-extend multiple temporaries. In passing, fix a
crasher (PR18217) if an initializer was dependent and exactly the wrong shape,
and remove a bogus function (Expr::findMaterializedTemporary) now its last use
is gone.
llvm-svn: 197103
Previously, a line like
// expected-error-re {{foo}}
treats the entirety of foo as a regex. This is inconvenient when matching type
names containing regex characters. For example, to match
"void *(class test8::A::*)(void)" inside such a regex, one would have to type
"void \*\(class test8::A::\*\)\(void\)".
This patch changes the semantics of expected-error-re to only treat the parts
of the directive wrapped in double curly braces as regexes. This avoids the
escaping problem and leads to nicer patterns for those cases; see e.g. the
change to test/Sema/format-strings-scanf.c.
(The balanced search for closing }} of a directive also makes us handle the
full directive in test\SemaCXX\constexpr-printing.cpp:41 and :53.)
Differential Revision: http://llvm-reviews.chandlerc.com/D2388
llvm-svn: 197092
Methods are thiscall by default in the MS ABI, and also in MinGW targetting GCC 4.7 or later.
This changes the diagnostic from the technically correct but hard to understand:
virtual function 'foo' has different calling convention attributes ('void ()') than the function it overrides (which has calling convention 'void () __attribute__((thiscall))')
to the more intuitive and also correct:
'static' member function 'foo' overrides a virtual function
We already have a test for this. Let's just run it in both ABI modes.
Differential Revision: http://llvm-reviews.chandlerc.com/D2375
llvm-svn: 197055
Add back the test that was triggering the assertion (which I removed mistakenly thinking it was triggering just a warning and not an assertion). My error was brought to my attention by Rafael (Thanks!).
llvm-svn: 196721
within their namespace, and such a redeclaration isn't required to be a
definition any more.
Update DR status page to say Clang 3.4 instead of SVN and add new Clang 3.5
category (but keep Clang 3.4 yellow for now).
llvm-svn: 196481
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
llvm-svn: 196454
Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar. The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.
Fixes PR17996.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2332
llvm-svn: 196451
nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.
llvm-svn: 196443
Clang currently croaks on the following:
struct X1 {
struct X2 {
int L = ([] (int i) { return i; })(2);
};
};
asserting that the containing lexical context of the lambda is not Sema's cur context, when pushing the lambda's decl context on.
This occurs because (prior to this patch) getContainingDC always returns the non-nested class for functions at class scope (even for inline member functions of nested classes (to account for delayed parsing of their bodies)). The patch addresses this by having getContainingDC always return the lexical DC for a lambda's call operator.
Link to the bug: http://llvm.org/bugs/show_bug.cgi?id=18052
Link to Richard Smith's feedback on phabricator: http://llvm-reviews.chandlerc.com/D2331
Thanks!
llvm-svn: 196423
The warning from cmake-clang-x64-msc16-R was:
test\SemaCXX\old-style-cast.cpp Line 6: cast to 'void **' from smaller integer type 'long'
llvm-svn: 195813
MSVC applies these to the following declaration only if present, otherwise
silently ignores them whereas we'll issue a warning.
Handling differs from ordinary attributes appearing in the same place, so add a
Sema test to make sure we get it right.
llvm-svn: 195577
data member definitions when the variable has an initializer
in its declaration.
For the following code:
struct S {
static const int x = 42;
};
const int S::x = 42;
This patch changes the diagnostic from:
a.cc:4:14: error: redefinition of 'x'
const int S::x = 42;
^
a.cc:2:20: note: previous definition is here
static const int x = 42;
^
to:
a.cc:4:18: error: static data member 'x' already has an initializer
const int S::x = 42;
^
a.cc:2:24: note: previous initialization is here
static const int x = 42;
^
Differential Revision: http://llvm-reviews.chandlerc.com/D2235
llvm-svn: 195306
The previous patches tried to deduce the correct function type. I now realize
this is not possible in general. Consider
class foo {
template <typename T> static void bar(T v);
};
extern template void foo::bar(const void *);
We will only know that bar is static after a lookup, so we have to handle this
in the template instantiation code.
This patch reverts my previous two changes (but not the tests) and instead
handles the issue in DeduceTemplateArguments.
llvm-svn: 195154
logic was not handling typedefs as free functions. This was not
causing problems with the existing tests, but does with the microsoft
abi where they have to get a different calling convention.
I will try to refactor this into a method on Declarator in a second.
llvm-svn: 195050
Before this patch explicit template instatiations of member function templates
were failing with the microsoft abi and 32 bits. This was happening because
the expected and computed function types had different calling conventions.
This patch fixes it by considering the default calling convention in
GetFullTypeForDeclarator.
This fixes pr17973.
llvm-svn: 195032
Earlier versions discarded the state too soon, and did not track state changes,
e.g. when passing a temporary to a move constructor. Patch by
chris.wailes@gmail.com; review and minor fixes by delesley.
llvm-svn: 194900
the GNU documentation: the attribute only appertains to the label if it is
followed by a semicolon. Based on a patch by Aaron Ballman!
llvm-svn: 194869
By adding a default config.excludes pattern we can avoid individual
suppressions in subdirectories.
This matches LLVM's lit.cfg which also excludes a few other common non-test
filenames for consistency.
llvm-svn: 194814
where we didn't. Extend our constant evaluation for __builtin_strlen to handle
any constant array of chars, not just string literals, to match.
llvm-svn: 194762
bit fields of zero size. Warnings are generated in C++ mode and if
only such type is defined inside extern "C" block.
The patch fixed PR5065.
Differential Revision: http://llvm-reviews.chandlerc.com/D2151
llvm-svn: 194653
We already have builtins that are only available in GNU mode, so this
mirrors that.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2128
llvm-svn: 194615
This patch fixes PR8264. Duplicate qualifiers already are diagnozed,
now the same diagnostics is issued for duplicate function specifiers.
Differential Revision: http://llvm-reviews.chandlerc.com/D2025
llvm-svn: 194559
See http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-November/033369.html for discussion on cfe-dev.
This fix explicitly checks whether we are within the declcontext of a lambda's call operator - which is what I had intended to be true (and assumed would be true if getCurLambda returns a valid pointer) before checking whether a lambda can capture the potential-captures of the innermost lambda.
A deeper fix (that addresses why getCurLambda() returns a valid pointer when perhaps it shouldn't?) - as proposed by Richard Smith in http://llvm.org/bugs/show_bug.cgi?id=17877 - has been suggested as a FIXME.
Patch was LGTM'd by Richard (just barely :)
http://llvm-reviews.chandlerc.com/D2144
llvm-svn: 194448
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!
llvm-svn: 194188
bit more robust against future changes. This includes a slight diagnostic
improvement: if we know we're only trying to form a constant expression, take
the first diagnostic which shows the expression is not a constant expression,
rather than preferring the first one which makes the expression unfoldable.
llvm-svn: 194098
Similar C code isn't caught as it seems to hit a different code path.
Also, as the check is only done for record pointers, cases involving
an overloaded operator-> are not handled either. Note that the reason
this check is done in the parser instead of Sema is not related to
having enough knowledge about the current state as it is about being
able to fix up the parser's state to be able to recover and traverse the
correct code paths.
llvm-svn: 194002
If the sole distinction between two declarations is that one has a
__restrict qualifier then we should not consider it to be an overload.
Instead, we will consider it as an incompatible redeclaration which is
similar to how MSVC, ICC and GCC would handle it.
This fixes PR17786.
N.B. We must not mangle in __restrict into method qualifiers becase we
don't allow overloading between such declarations anymore. To do
otherwise would be a violation of the Itanium ABI.
llvm-svn: 193964
Flexible array members only work out if they are the last field of a
record, however virtual bases would give us many situations where the
flexible array member would overlap with the virtual base fields.
It is unlikely in the extreme that this behavior was intended by the
user so raise a diagnostic instead of accepting. This is will not
reject conforming code because flexible array members are an extension
in C++ mode.
llvm-svn: 193920
The determination of which diagnostics would be issued for certain
anonymous unions started to get a little ridiculous. Clean this up by
inverting the condition-tree's logic from dialect -> issue to
issue -> diagnostic.
As part of this cleanup, move ext_c99_flexible_array_member from
DiagnosticParseKinds.td to DiagnosticSemaKinds.td because it's driven by
Sema, not Parse.
Also, the liberty was taken to edit ext_c99_flexible_array_member to
match other, similar, diagnostics.
llvm-svn: 193919
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!
llvm-svn: 193418
Change the uninitialized field warnings so that field initializers are checked
inside the constructor. Previously, in class initializers were checked
separately. Running one set of checks also simplifies the logic for preventing
duplicate warnings. Added new checks to warn when an uninitialized field is
used in base class initialization. Also fixed misspelling of uninitialized
and moved all code for this warning together.
llvm-svn: 193386
This patch fixes the typelocs of the conversion-operator and the conversion-operator-name and adds the parameters of the call operator to the FunctionProtoTypeLoc of the respective entities. Thus, when the template declarations (conversion operators) undergo deduction and instantiation/transformation/substitution - they add themselves to the local instantiation scope if needed.
This patch supports the following:
auto L = [](auto b) {
return [](auto a) ->decltype(a) { return a; };
};
int (*fp)(int) = L(8);
Richard LGTM'd this patch: http://llvm-reviews.chandlerc.com/D1831
Thanks!
llvm-svn: 193294
A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,
The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.
The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.
Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh!
Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date.
Hopefully the third time;s a charm *fingers crossed*
This does not yet include capturing.
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
llvm-svn: 193230
They were causing CodeGenCXX/mangle-exprs.cpp to fail.
Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."
Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."
llvm-svn: 193226
lambdas nested within templates and themselves.
A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,
The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.
The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.
This does not yet include capturing.
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
llvm-svn: 193216
With this extension, friend function declarations will retain the language
linkage specified for previous declarations instead of emitting an error
diagnostic.
The feature is known to be compatible with GCC and MSVC and permits a
language to be specified indirectly where it cannot otherwise be written
directly in class scope.
Work is ongoing to improve linkage spec diagnostics.
Fixes PR17337.
Reviewed by Richard Smith.
llvm-svn: 193206
This fixes pr17624.
A FIXME from Richard Smith:
It seems to me that the root cause is that a per-Decl 'used' flag doesn't
really make much sense in the way we use it now. I think we should either track
whether that particular declaration is used (with isUsed scanning the entire
redecl chain), or we should only have one flag for the entire redeclaration
chain (perhaps by always looking at the flag on either the most recent decl or
the canonical decl). Modeling it as "is this declaration or any previous
declaration used" is weird, and requires contortions like the loop at the end
of Sema::MarkFunctionReferenced.
llvm-svn: 193202
ResolveSingleFunctionTemplateSpecialization() returns 0 and doesn't emit diags
unless the expression has template-ids, so we must null check the result.
Also add a better diag noting which overloads are causing the problem.
Reviewed by Aaron Ballman.
llvm-svn: 193055
This fixes PR17591.
N.B. This actually goes beyond what the standard mandates by requiring
the restriction to hold for declarations instead of definitions. This
is believed to be a defect in the standard and an LWG issue has been
submitted.
llvm-svn: 193044
Now that CorrectTypo knows how to correctly search classes for typo
correction candidates, there is no good reason to only replace an
existing CXXScopeSpecifier if it refers to a namespace. While the actual
enablement was a matter of changing a single comparison, the fallout
from enabling the functionality required a lot more code changes
(including my two previous commits).
llvm-svn: 193020
Summary: Some MS headers use these features.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1948
llvm-svn: 192936
to be treated as return values, and marked with the "returned_typestate"
attribute. Patch by chris.wailes@gmail.com; reviewed by delesley@google.com.
llvm-svn: 192932
We wouldn't transform the compound statement in any of these forms,
causing crashes when it got time to act on them. Additionally, we
wouldn't check to see if the handler was invalid before deciding whether
or not we should continue acting on the __try.
This fixes PR17584.
llvm-svn: 192682
that looks like a function declaration, except that it's missing a return type,
try typo-correcting it to the relevant constructor name.
In passing, fix a bug where the missing-type-specifier recovery codepath would
drop a preceding scope specifier on the floor, leading to follow-on diagnostics
and incorrect recovery for the auto-in-c++98 hack.
llvm-svn: 192644
This patch fixes PR17019. When doing typo correction, Sema::CorrectTypo uses
correction already seen for the same typo. This causes problems if that
correction is from another scope and cannot be accessed in the current.
llvm-svn: 192594
function parameter that has array type. Such a parameter will be treated as
a pointer type instead, resulting in a missing begin function error is a
suggestion to dereference the pointer. This provides a different,
more informative diagnostic as well as point to the parameter declaration.
llvm-svn: 192512
This allows the callable_when attribute to be attached to destructors.
Original patch by chris.wailes@gmail.com, reviewed and edited by delesley.
llvm-svn: 192508
marked all variables as "unknown" at the start of a loop. The new version
keeps the initial state of variables unchanged, but issues a warning if the
state at the end of the loop is different from the state at the beginning.
This patch will eventually be replaced with a more precise analysis.
Initial patch by chris.wailes@gmail.com. Reviewed and edited by
delesley@google.com.
llvm-svn: 192314
Follow-up from r192240.
This makes it an error to use callee-cleanup conventions on variadic
functions, except for __fastcall and __stdcall, which we ignore with
a warning for GCC and MSVC compatibility.
Differential Revision: http://llvm-reviews.chandlerc.com/D1870
llvm-svn: 192308
In r186373, we started merging attributes on typedefs, but this causes
us to try to merge attributes even if the previous declaration was not
a typedef.
Only merge the attributes if the previous decl was also a typedef.
Fixes rdar://problem/15044218
llvm-svn: 192146
that a function can be called in. This reduced the total number of annotations
needed and makes writing more complicated behaviour less burdensome.
Patch by chriswails@gmail.com.
llvm-svn: 191983
This does not yet include capturing (that is next).
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090048.html
When I first committed this patch - a bunch of buildbots were unable to compile the code that VS2010 seemed to compile. Seems like there was a dependency on Sema/Template.h which VS did not seem to need, but I have now added for the other compilers. It still compiles on Visual Studio 2010 - lets hope the buildbots remain quiet (please!)
llvm-svn: 191879
This does not yet include capturing (that is next).
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
llvm-svn: 191875
When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent).
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191727
When we check access for lookup results, make sure we propagate the
result's access to the access control APIs; this can be different from
the natural access of the declaration depending on the path used by the lookup.
PR17394.
llvm-svn: 191726
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.)
llvm-svn: 191719
When nested lambdas are used in NSDMI's - this prevents infinite recursion.
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191645
The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator.
This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM.
A few minor changes:
- per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation).
- I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively.
- Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming.
Thanks!
llvm-svn: 191634
Move some tests from typo-correction.cpp to typo-correction-pt2.cpp
because they were running afoul of the hard-coded limit of 20 typos
corrected. Some of the tests after it were still working due to the
limit not applying to cached corrections and in cases where a non-NULL
MemberContext is passed in to Sema::CorrectTypo. Most of the moved tests
still passed after being moved, but the test involving "data_struct" had
only been passing because the test had exceeded that limit so a fix for
it is also included (most of the changes to ParseStmt.cpp are shared with
and originated from another typo correction impovement that was split
into a separate commit).
llvm-svn: 191544
Unlike with namespaces, searching inside of classes requires also
checking the access to correction candidates (i.e. don't suggest a
correction to a private class member for a correction occurring outside
that class and its methods or friends).
Included is a small (one line) fix for a bug, that was uncovered while
cleaning up the unit tests, where the decls from a TypoCorrection candidate
were preserved in new TypoCorrection candidates that are derived (copied)
from the old TypoCorrection--notably when creating a new candidate by
changing the NestedNameSpecifier associated with the base idenitifer.
llvm-svn: 191449
literal operators. Also, for now, allow the proposed C++1y "il", "i", and "if"
suffixes too. (Will revert the latter if LWG decides not to go ahead with that
change after all.)
llvm-svn: 191274
an additional conversion (other than a qualification conversion) would be
required after the explicit conversion.
Conversely, do allow explicit conversion functions to be used when initializing
a temporary for a reference binding in direct-list-initialization.
llvm-svn: 191150
fields in the class. This allows a better checking of member intiailizers and
in class initializers in regards to initialization ordering.
For instance, this code will now produce warnings:
class A {
int x;
int y;
A() : x(y) {} // y is initialized after x, warn here
A(int): y(x) {} // default initialization of leaves x uninitialized, warn here
};
Several test cases were updated with -Wno-uninitialized to silence this warning.
llvm-svn: 191068
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.
llvm-svn: 191064
Before this patch, Lex() would recurse whenever the current lexer changed (e.g.
upon entry into a macro). This patch turns the recursion into a loop: the
various lex routines now don't return a token when the current lexer changes,
and at the top level Preprocessor::Lex() now loops until it finds a token.
Normally, the recursion wouldn't end up being very deep, but the recursion depth
can explode in edge cases like a bunch of consecutive macros which expand to
nothing (like in the testcase test/Preprocessor/macro_expand_empty.c in this
patch).
<rdar://problem/14569770>
llvm-svn: 190980
This patch adds the following, more specific warning flags:
gnu-anonymous-struct
gnu-compound-literal-initializer
gnu-empty-struct
gnu-flexible-array-initializer
gnu-flexible-array-union-member
gnu-folding-constant
redeclared-class-member
gnu-redeclared-enum
gnu-union-cast
gnu-variable-sized-type-not-at-end
Patch by Peter Lewis.
llvm-svn: 190972
Summary:
This fixes several issues with the original implementation:
- Win32 entry points cannot be in namespaces
- A Win32 entry point cannot be a function template, diagnose if we it.
- Win32 entry points cannot be overloaded.
- Win32 entry points implicitly return, similar to main.
Reviewers: rnk, rsmith, whunt, timurrrr
Reviewed By: rnk
CC: cfe-commits, nrieck
Differential Revision: http://llvm-reviews.chandlerc.com/D1683
llvm-svn: 190818
Summary:
- lambdas, blocks or captured statements in templates were not
handled which causes codegen crashes.
Differential Revision: http://llvm-reviews.chandlerc.com/D1628
llvm-svn: 190784
This is a fix to PR12778: in erroneous code an allocation function
can be declared with no arguments, quering the first argument in this case
causes assertion violation.
llvm-svn: 190751
later in the code so that the expressions will have addition processing first.
This catches a few additional cases of uninitialized uses of class fields.
llvm-svn: 190657
With r190382, -Wunused-variable warns about unused const variables when
appropriate. For codebases that use -Werror, this poses a problem as
existing unused const variables need to be cleaned up first. To make the
transistion easier, this patch splits -Wunused-variable by pulling out
an additional -Wunused-const-variable (by default activated along with
-Wunused-variable).
llvm-svn: 190508
Make sure we perform the correct "referenced-but-not-used" check for
static member constants.
Fixes bug reported on cfe-commits by Alexey Samsonov.
llvm-svn: 190437
This patch does a few different things.
This patch improves unused var diags for const vars: we no longer
unconditionally suppress diagnostics for const vars, instead only suppressing
the diagnostic when the declaration appears to be useful.
This patch also makes us more consistently use whether a variable/function
is declared in the main file to suppress diagnostics where appropriate.
Fixes <rdar://problem/14907887>.
llvm-svn: 190382
Richard Smith