Faisal Vali [Thu, 7 Nov 2013 16:57:56 +0000 (16:57 +0000)]
Remove an unnecessary condition that I added hastily: Unsigned numbers are obviously >= 0 ;)
Also - others have complained about some white space issues - sorry about that - continues to be a pain point for me - will try and see what I can do with clang-format this evening after work - as a short term fix, if anyone can email me the files that they have already identified with issues, it would help me speed up a focused fix. sorry.
Faisal Vali [Thu, 7 Nov 2013 05:17:06 +0000 (05:17 +0000)]
This patch implements capturing of variables within generic lambdas.
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 ;)
Add the fact that Clang too is planning to start using C++11 (in some
limited ways) after the next release. See the lengthy discussions (which
are on-going) and the corresponding commit to LLVM's release notes.
Nothing is actually changing at this point, this is just further
spreading the plan.
David Majnemer [Wed, 6 Nov 2013 23:31:56 +0000 (23:31 +0000)]
[-fms-extensions] Add support for __FUNCDNAME__
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.
Introduce ClangTool::buildASTs, and buildASTFromCode.
These allow clients to retrieve persistent AST objects (ASTUnits) which
can be used in an ad-hoc manner after parsing.
To accommodate this change, the code for processing a CompilerInvocation
using a FrontendAction has been factored out to FrontendActionFactory, and
a new base class, ToolAction, has been introduced, allowing the tool to do
arbitrary things with each CompilerInvocation. This change was necessary
because ASTUnit does not use the FrontendAction interface directly.
This change also causes the FileManager in ClangTool to use shared ownership.
This will become necessary because ASTUnit takes shared ownership of
FileManager (ClangTool's FileManager is currently unused by ASTUnit; this
is a FIXME). As shown in the tests, any client of ToolInvocation will
need to be modified to use shared ownership for FileManager.
Richard Smith [Wed, 6 Nov 2013 19:31:51 +0000 (19:31 +0000)]
Add a limit to the length of a sequence of 'operator->' functions we will
follow when building a class member access expression. Based on a patch by
Rahul Jain!
Richard Smith [Wed, 6 Nov 2013 02:19:10 +0000 (02:19 +0000)]
More constant evaluation cleanup, and fix an issue where we'd override an
earlier 'non-constant' diagnostic with a later one if the earlier one was from
a side-effect we thought we could evaluate past.
ObjectiveC migrator. Please annotation of properties with
NS_RETURNS_INNER_POINTER under -objcmt-returns-innerpointer-property
flag (off by default), as older compilers do not support such annotations.
// rdar://15396636
Richard Smith [Tue, 5 Nov 2013 22:18:15 +0000 (22:18 +0000)]
Refactor constant expression handling and make a couple of tweaks to make it a
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.
With this patch -Wwrite-strings is still implemented with the terrible
hack of passing -fconst-strings to -cc1, but at least the driver uses
the regular warning checking code path.
Since we don't support a warning that is DefaultIgnore in one language
but not in another, this patch creates a dummy C only warning in the same
group as the existing one to get the desired effect.
James Dennett [Tue, 5 Nov 2013 19:37:38 +0000 (19:37 +0000)]
Documentation tweaks: Fix a typo in a reference to the C++ standard,
another typo in a comment, and update formatting of some comments to
use Doxygen \brief annotations instead of repeating the name of the
documented entity.
Daniel Jasper [Tue, 5 Nov 2013 19:10:03 +0000 (19:10 +0000)]
clang-format: Allow line merging and partial formatting of nested blocks
Before, clang-format would always format entire nested blocks, which
can be unwanted e.g. for long DEBUG({...}) statements. Also
clang-format would not allow to merge lines in nested blocks (e.g. to
put "if (a) return;" on one line in Google style).
This is the first step of several refactorings mostly focussing on the
additional functionality (by reusing the "format many lines" code to
format the children of a nested block). The next steps are:
* Pull out the line merging into its own class.
* Seperate the formatting of many lines from the formatting of a single
line (and the analysis of the solution space).
Alp Toker [Tue, 5 Nov 2013 12:45:46 +0000 (12:45 +0000)]
Fix a test that was never being run, mark it XFAIL
Turns out this has always been crashing since the test landed in
r186647:
Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function CheckAccessDeclContext, file clang/lib/AST/DeclBase.cpp, line 690.
David Majnemer [Tue, 5 Nov 2013 09:30:17 +0000 (09:30 +0000)]
Lex: Require that '#' be followed by a macro parameter name when preceded by '##'
After lexing a '##', we would look ahead and check to see if it was
followed by '__VA_ARGS__'. After doing so, we would then go ahead and
lex the token.
However we would fail in the case where the '##' was followed by a '#'
followed by an identifier because we would have lexed the '#' separately
from the identifier, bypassing our parameter validation logic.
Instead, lex the tokens coming after the '##' later.
Richard Smith [Tue, 5 Nov 2013 09:12:18 +0000 (09:12 +0000)]
C++1y sized deallocation: if we have a use, but not a definition, of a sized
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.
This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.
ObjectiveC. Method implementations should only check for
"Missing call to Super" in the overriding method and
not in the method itself. // rdar://15385981.
Dmitri Gribenko [Mon, 4 Nov 2013 21:51:33 +0000 (21:51 +0000)]
Include non-explicit submodules in exported module list
This change fixes Richard's testcase for r193815. Now we include non-explicit
submodules into the list of exports.
The test failed previously because:
- recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is),
- thus the 'inner' submodule is not showing up in any of the import lists,
- and because of this getExportedModules() is not returning the
correct module set -- it only considers modules that are imported.
The fix is to make Module::getExportedModules() include non-explicit submodules
into the list of exports.
Kaelyn Uhrain [Mon, 4 Nov 2013 18:59:34 +0000 (18:59 +0000)]
Try to correct a mistyped "-" or ">" to "->" for some C++ cases.
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.
Justin Bogner [Mon, 4 Nov 2013 16:13:21 +0000 (16:13 +0000)]
CodeGen: Use EmitBranchOnBool when generating For and CXXForRange
A while ago EmitForStmt was changed to explicitly evaluate the
condition expression and create a branch instead of using
EmitBranchOnBool, so that the condition expression could be used for
some cleanup logic. The cleanup stuff has since been reorganized, and
this is no longer necessary.
In EmitCXXForRange, the evaluated condition was never used for
anything else. The logic was presumably modeled on EmitForStmt.
Justin Bogner [Mon, 4 Nov 2013 16:13:18 +0000 (16:13 +0000)]
CodeGen: Move an initialization away from an unrelated comment
An initialization somehow found its way in between a comment and the
block of code the comment is about. Moving the initialization makes
this less confusing.
Aaron Ballman [Mon, 4 Nov 2013 12:55:56 +0000 (12:55 +0000)]
Attributes which accept a type as their sole argument are no longer hard coded into the parser. Instead, they are automatically listed through tablegen.
Richard Smith [Mon, 4 Nov 2013 04:26:14 +0000 (04:26 +0000)]
Issue a diagnostic if an implicitly-defined move assignment operator would move
the same virtual base class multiple times (and the move assignment is used,
and the move assignment for the virtual base is not trivial).
Richard Smith [Mon, 4 Nov 2013 01:48:18 +0000 (01:48 +0000)]
Implement final resolution of DR1402: implicitly-declared move operators that
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
David Majnemer [Sun, 3 Nov 2013 23:51:28 +0000 (23:51 +0000)]
Sema: Do not allow overloading between methods based on restrict
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.
David Majnemer [Sat, 2 Nov 2013 12:00:36 +0000 (12:00 +0000)]
Sema: Disallow inheriting from classes with flexible array members
Flexible array members inherently index off of the end of their parent
type.
We shouldn't allow this type to be used as a base, virtual or otherwise,
because indexing off the end may find us inside of another base or the
derived types members.
David Majnemer [Sat, 2 Nov 2013 11:19:13 +0000 (11:19 +0000)]
Sema: Disallow derived classes with virtual bases from having flexible array members
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.
David Majnemer [Sat, 2 Nov 2013 10:38:05 +0000 (10:38 +0000)]
Sema: Cleanup and simplify anonymous union diagnostics
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.
projects / clang / log