| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 194200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 194181
|
|
|
|
|
|
|
| |
specializations. Also switch to -Wuninitialized for a test case that depended
on a warning firing in template specializations.
llvm-svn: 193906
|
|
|
|
|
|
|
|
|
|
|
| |
-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
llvm-svn: 193889
|
|
|
|
|
|
| |
in my last patch. // rdar://14989999
llvm-svn: 193441
|
|
|
|
|
|
|
| |
backing warning is not used in one of its accessor methods.
// rdar://14989999
llvm-svn: 193439
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
We would previously not diagnose this which would lead to crashes (on
very strange code).
This fixes PR17675.
llvm-svn: 193397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 193274
|
|
|
|
| |
llvm-svn: 193026
|
|
|
|
|
|
| |
Every other function in Redeclarable.h was using Decl instead of Declaration.
llvm-svn: 192900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 192727
|
|
|
|
|
|
|
|
|
|
| |
virtual base
icc 13 and g++ 4.9 both reject this while we would crash.
Fixes PR17578.
llvm-svn: 192674
|
|
|
|
|
|
| |
Fixes <rdar://problem/14468891>.
llvm-svn: 192419
|
|
|
|
|
|
| |
Emit a proper error instead of crashing in CodeGen. PR16892.
llvm-svn: 192345
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 192177
|
|
|
|
|
|
|
|
|
| |
extension. The GCC folks have decided to support this even though the standard
committee have not yet approved this feature.
Patch by Hristo Venev!
llvm-svn: 192128
|
|
|
|
|
|
| |
IsBlock, and IsLambda. [-Wunused-variable]
llvm-svn: 192095
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 192087
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 191606
|
|
|
|
|
|
| |
appropriately, especially when they appear within class templates.
llvm-svn: 191548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 191484
|
|
|
|
|
|
|
|
| |
I noticed the wrong text was being replaced with the correction while
working on expanding the "namespace-aware" typo correction to include
classes.
llvm-svn: 191450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 190915
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/14970968>
llvm-svn: 190635
|
|
|
|
|
|
|
| |
treat such subtractions as being non-constant. Patch by Serge Pavlov! With a
few tweaks by me.
llvm-svn: 190439
|
|
|
|
|
|
|
|
|
|
| |
vector types,
so allow that case and add appropriate tests.
Patch by Ruiling Song!
llvm-svn: 190129
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 190118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 190016
|
|
|
|
|
|
| |
Found by Chris Wailes
llvm-svn: 189859
|
|
|
|
|
|
| |
CheckVectorOperands on CheckConditionalOperands function. This problem caused compilation error with test17 on "test/CodeGen/ext-vector.c".
llvm-svn: 189773
|
|
|
|
|
|
|
|
|
|
|
| |
- __func__ or __FUNCTION__ returns captured statement's parent
function name, not the one compiler generated.
Differential Revision: http://llvm-reviews.chandlerc.com/D1491
Reviewed by bkramer
llvm-svn: 189219
|
|
|
|
|
|
|
|
|
| |
Basically, isInMainFile considers line markers, and isWrittenInMainFile
doesn't. Distinguishing between the two is useful when dealing with
files which are preprocessed files or rewritten with -frewrite-includes
(so we don't, for example, print useless warnings).
llvm-svn: 188968
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. We now print the return type of lambdas and return type deduced functions
as "auto". Trailing return types with decltype print the underlying type.
2. Use the lambda or block scope for the PredefinedExpr type instead of the
parent function. This fixes PR16946, a strange mismatch between type of the
expression and the actual result.
3. Verify the type in CodeGen.
4. The type for blocks is still wrong. They are numbered and the name is not
known until CodeGen.
llvm-svn: 188900
|
|
|
|
|
|
| |
checking for missing parens in &&/|| expressions.
llvm-svn: 188716
|
|
|
|
|
|
|
| |
preparation for teaching this function how to diagnose a correction that
includes importing a module.
llvm-svn: 188602
|
|
|
|
|
|
| |
PR16900.
llvm-svn: 188511
|
|
|
|
|
|
| |
PR16872.
llvm-svn: 188324
|
|
|
|
|
|
| |
include/clang/Basic/LLVM.h.
llvm-svn: 188089
|
|
|
|
|
|
| |
Fixes PR16394.
llvm-svn: 187955
|
|
|
|
|
|
| |
fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...
llvm-svn: 187762
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function: it can't be 'void' and it can't be an initializer list. We give a
hard error for these rather than treating them as undefined behavior (we can
and probably should do the same for non-POD types in C++11, but as of this
change we don't).
Slightly rework the checking of variadic arguments in a function with a format
attribute to ensure that certain kinds of format string problem (non-literal
string, too many/too few arguments, ...) don't suppress this error.
llvm-svn: 187735
|
|
|
|
|
|
|
|
|
| |
Sema::PerformObjectMemberConversion assumed that the Qualifier it was
given holds a type. However, the specifier could hold just a namespace.
In this case, we should ignore the qualifier and not attempt to cast to
it.
llvm-svn: 187715
|
|
|
|
|
|
|
| |
retainable pointer is passed to an audited CF function
expecting CF type. // rdar://14569171
llvm-svn: 187543
|
|
|
|
|
|
|
|
| |
passing a retainable object arg to a CF audited function
expecting a CF object type. Issue a normal type mismatch
diagnostic. This is wip // rdar://14569171
llvm-svn: 187532
|
|
|
|
|
|
| |
to avoid future false positives. // rdar://14569171
llvm-svn: 187509
|