| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference.
Under ARC++, a reference to a const Objective-C pointer is implicitly
treated as __unsafe_unretained, and can be initialized with (e.g.) a
__strong lvalue. Make sure this behavior does not break template
argument deduction and (related) that partial ordering still prefers a
'T* const&' template over a 'T const&' template when this case kicks
in. Fixes <rdar://problem/14467941>.
llvm-svn: 194239
|
|
|
|
| |
llvm-svn: 194237
|
|
|
|
|
|
|
|
|
| |
When performing an Objective-C message send to a value of class type,
perform a contextual conversion to an Objective-C pointer type. We've
had this for a long time, but it recently regressed. Fixes
<rdar://problem/15234703>.
llvm-svn: 194224
|
|
|
|
|
|
|
| |
to avoid breaking AST invariants by reusing Stmt nodes within the same
function.
llvm-svn: 194217
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 194206
|
|
|
|
| |
llvm-svn: 194200
|
|
|
|
| |
llvm-svn: 194197
|
|
|
|
| |
llvm-svn: 194190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 194162
|
|
|
|
|
|
|
| |
follow when building a class member access expression. Based on a patch by
Rahul Jain!
llvm-svn: 194161
|
|
|
|
|
|
| |
checking an expression for constant overflow.
llvm-svn: 194099
|
|
|
|
| |
llvm-svn: 194068
|
|
|
|
| |
llvm-svn: 194052
|
|
|
|
|
|
|
| |
"Missing call to Super" in the overriding method and
not in the method itself. // rdar://15385981.
llvm-svn: 194031
|
|
|
|
|
|
|
| |
the same virtual base class multiple times (and the move assignment is used,
and the move assignment for the virtual base is not trivial).
llvm-svn: 193977
|
|
|
|
| |
llvm-svn: 193970
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 193969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
llvm-svn: 193923
|
|
|
|
| |
llvm-svn: 193922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
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
|
|
|
|
|
|
|
| |
The declaration of a flexible array member was correctly diagnosed as an
extension in C89 mode but not in C++.
llvm-svn: 193918
|
|
|
|
| |
llvm-svn: 193917
|
|
|
|
| |
llvm-svn: 193916
|
|
|
|
|
|
|
| |
specializations. Also switch to -Wuninitialized for a test case that depended
on a warning firing in template specializations.
llvm-svn: 193906
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2082
Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct
behavior for builtins in a variety of cases without special treatment elsewhere within
the compiler (special treatment is removed by the patch). It also allows for C++
overloads of builtin functions, which Microsoft uses in their headers e.g.
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper
for int type.
llvm-svn: 193896
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
| |
llvm-svn: 193888
|
|
|
|
| |
llvm-svn: 193887
|
|
|
|
| |
llvm-svn: 193857
|
|
|
|
|
|
| |
QualType with a SourceLocation stashed alongside.
llvm-svn: 193803
|
|
|
|
| |
llvm-svn: 193799
|
|
|
|
|
|
|
|
|
| |
into a separate "parse an attribute that takes a type argument" codepath. This
results in both codepaths being a lot cleaner and simpler, and fixes some bugs
where the type argument handling bled into the expression argument handling and
caused us to both accept invalid and reject valid attribute arguments.
llvm-svn: 193731
|
|
|
|
|
|
|
| |
scope, be careful about function-scope declarations (which are not declared in
their semantic context).
llvm-svn: 193671
|
|
|
|
| |
llvm-svn: 193648
|
|
|
|
|
|
|
|
|
|
|
| |
The AST was constructed so that this builtin returned the default BoolTy and
since I'd opted for custom SemaChecking, I should have set it properly at that
point.
This caused an assertion failure when the types didn't match up with what we
generated. This makes it return an IntTy, which is as good as anything.
llvm-svn: 193606
|
|
|
|
|
|
| |
inappropriately in non-type template arguments
llvm-svn: 193462
|
|
|
|
|
|
|
|
|
|
|
|
| |
with an IndirectFieldDecl
We only considered FieldDecl and CXXMethodDecl as appropriate which
would cause us to believe the IndirectFieldDecl corresponded to an
argument of it's field type instead of a pointer-to-member type.
This fixes PR17696.
llvm-svn: 193461
|
|
|
|
|
|
|
| |
is redeclared as 'weak' in class extension.
// rdar://15304886
llvm-svn: 193453
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Without this patch we would warn and fail to output the function in the test.
llvm-svn: 193388
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversion to fptr deduction into its own function.
No functionality change.
All clang regression tests pass.
Thanks!
llvm-svn: 193383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|