summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
* Unbreak the Clang -Werror build by removing some unused variablesDavid Blaikie2013-11-071-11/+6
| | | | llvm-svn: 194190
* This patch implements capturing of variables within generic lambdas.Faisal Vali2013-11-076-57/+504
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [-fms-extensions] Add support for __FUNCDNAME__David Majnemer2013-11-061-0/+1
| | | | | | | | | | | | | | | | 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
* Fix diagnostic goof in r194161.Richard Smith2013-11-061-2/+2
| | | | llvm-svn: 194162
* Add a limit to the length of a sequence of 'operator->' functions we willRichard Smith2013-11-061-6/+41
| | | | | | | follow when building a class member access expression. Based on a patch by Rahul Jain! llvm-svn: 194161
* Simplify: we don't care why constant evaluation might have failed when we'reRichard Smith2013-11-051-4/+2
| | | | | | checking an expression for constant overflow. llvm-svn: 194099
* Do not allow functions or kernels called 'main' in OpenCL.Joey Gouly2013-11-051-0/+7
| | | | llvm-svn: 194068
* Sema: Improve comment introduced in r193397David Majnemer2013-11-051-0/+5
| | | | llvm-svn: 194052
* ObjectiveC. Method implementations should only check forFariborz Jahanian2013-11-051-3/+1
| | | | | | | "Missing call to Super" in the overriding method and not in the method itself. // rdar://15385981. llvm-svn: 194031
* Issue a diagnostic if an implicitly-defined move assignment operator would moveRichard Smith2013-11-041-10/+99
| | | | | | | 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
* Update a comment to match current core issues list.Richard Smith2013-11-041-8/+3
| | | | llvm-svn: 193970
* Implement final resolution of DR1402: implicitly-declared move operators thatRichard Smith2013-11-043-157/+33
| | | | | | | | | | | 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
* Sema: Do not allow overloading between methods based on restrictDavid Majnemer2013-11-031-1/+6
| | | | | | | | | | | | | | | | 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
* Sema: Disallow inheriting from classes with flexible array membersDavid Majnemer2013-11-021-0/+12
| | | | | | | | | | | 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
* Sema: Remove stray whitespace around Sema::CheckBaseSpecifierDavid Majnemer2013-11-021-3/+3
| | | | llvm-svn: 193922
* Sema: Disallow derived classes with virtual bases from having flexible array ↵David Majnemer2013-11-021-0/+9
| | | | | | | | | | | | | | | 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
* Sema: Cleanup and simplify anonymous union diagnosticsDavid Majnemer2013-11-021-34/+23
| | | | | | | | | | | | | | | | 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
* Sema: Flexible array members were introduced in C99, diagnose their use in C++David Majnemer2013-11-021-0/+6
| | | | | | | The declaration of a flexible array member was correctly diagnosed as an extension in C89 mode but not in C++. llvm-svn: 193918
* Sema: Properly indent statements in Sema::ActOnLastBitfieldDavid Majnemer2013-11-021-6/+6
| | | | llvm-svn: 193917
* Sema: trim trailing whitespace in Sema::ActOnLastBitfieldDavid Majnemer2013-11-021-4/+4
| | | | llvm-svn: 193916
* Change the other -Wtautological-compare warnings to not trigger in templateRichard Trieu2013-11-021-2/+4
| | | | | | | specializations. Also switch to -Wuninitialized for a test case that depended on a warning firing in template specializations. llvm-svn: 193906
* Wraps lazily generated builtins in an extern "C" contextWarren Hunt2013-11-011-4/+14
| | | | | | | | | | | | | 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
* ObjectiveC. Define a new cc1 flag Fariborz Jahanian2013-11-012-9/+5
| | | | | | | | | | | -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
* Disable -Wtautological-compare in template instantiations.Richard Trieu2013-11-011-0/+4
| | | | llvm-svn: 193888
* Disable -Wtautological-constant-out-of-range-compare in template instantiations.Richard Trieu2013-11-011-0/+4
| | | | llvm-svn: 193887
* Sema: Make helper function static.Benjamin Kramer2013-11-011-1/+1
| | | | llvm-svn: 193857
* Store a TypeArgument on an attribute as a TypeSourceInfo*, rather than as aRichard Smith2013-10-312-20/+23
| | | | | | QualType with a SourceLocation stashed alongside. llvm-svn: 193803
* Fix a C struct diagnostic regression introduced by r187504 (PR17762).Kaelyn Uhrain2013-10-311-0/+5
| | | | llvm-svn: 193799
* Factor out custom parsing for iboutletcollection and vec_type_hint attributesRichard Smith2013-10-311-18/+22
| | | | | | | | | 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
* PR17731: When determining whether a tag and a non-tag were declared in the sameRichard Smith2013-10-301-2/+17
| | | | | | | scope, be careful about function-scope declarations (which are not declared in their semantic context). llvm-svn: 193671
* Changed tests_typestate to test_typestate for consistency.Chris Wailes2013-10-291-7/+7
| | | | llvm-svn: 193648
* ARM: fix AST for __builtin_arm_strex callTim Northover2013-10-291-1/+4
| | | | | | | | | | | 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
* Sema: Emit a nicer diagnostic when IndirectFieldDecls show up ↵David Majnemer2013-10-261-2/+2
| | | | | | inappropriately in non-type template arguments llvm-svn: 193462
* Sema: Correctly build pointer-to-member arguments from a template argument ↵David Majnemer2013-10-261-1/+2
| | | | | | | | | | | | 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
* ObjectiveC arc. Warn when an implicitly 'strong' property Fariborz Jahanian2013-10-261-0/+14
| | | | | | | is redeclared as 'weak' in class extension. // rdar://15304886 llvm-svn: 193453
* Minor performance improvement to not do unnecessary workFariborz Jahanian2013-10-251-6/+8
| | | | | | in my last patch. // rdar://14989999 llvm-svn: 193441
* ObjectiveC: under -Wunused-property-ivar warn if property'sFariborz Jahanian2013-10-253-0/+38
| | | | | | | backing warning is not used in one of its accessor methods. // rdar://14989999 llvm-svn: 193439
* Add -Wstring-plus-char, which warns when adding char literals to C strings.Jordan Rose2013-10-251-4/+57
| | | | | | | | | | | 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
* Sema: Do not allow lambda expressions to appear inside of constant expressionsDavid Majnemer2013-10-252-10/+24
| | | | | | | | | We would previously not diagnose this which would lead to crashes (on very strange code). This fixes PR17675. llvm-svn: 193397
* Consider used attributes in hidden decls.Rafael Espindola2013-10-251-0/+10
| | | | | | Without this patch we would warn and fail to output the function in the test. llvm-svn: 193388
* Simplify and refactor the uninitialized field warning.Richard Trieu2013-10-251-190/+90
| | | | | | | | | | | 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
* Refactor: Extract specializing the generic lambda call operator during ↵Faisal Vali2013-10-241-141/+133
| | | | | | | | | | | | conversion to fptr deduction into its own function. No functionality change. All clang regression tests pass. Thanks! llvm-svn: 193383
* Fix an instantiation bug with nested generic lambdas and conversion to fptrs.Faisal Vali2013-10-241-41/+107
| | | | | | | | | | | | | | | | | 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
* Parse: Disable delayed template parsing for constexpr functionsDavid Majnemer2013-10-231-5/+3
| | | | | | | | | | | | | | | 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
* A decl never becomes unused. Make that explicit in the API.Rafael Espindola2013-10-232-3/+6
| | | | llvm-svn: 193248
* Refactor out the circular reference to LambdaExpr in CXXRecordDecl.Faisal Vali2013-10-233-48/+66
| | | | | | | | | | | | | | | | | A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box). Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl. In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. No change in functionality. This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): http://llvm-reviews.chandlerc.com/D1856 Thanks! llvm-svn: 193246
* And Again: Teach TreeTransform how to transform nested generic lambdas.Faisal Vali2013-10-233-34/+139
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r193223 and r193216.Rafael Espindola2013-10-235-188/+83
| | | | | | | | | | 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
* Remove the circular reference to LambdaExpr in CXXRecordDecl.Faisal Vali2013-10-233-48/+66
| | | | | | | | | | | | | | | Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl. No change in functionality. In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): http://llvm-reviews.chandlerc.com/D1856 Thanks! llvm-svn: 193223
* Make UsingShadowDecls redeclarable. This fixes some visibility problems withRichard Smith2013-10-232-28/+37
| | | | | | | | | | modules. With this fixed, I no longer see any test regressions in the libc++ test suite when enabling a single-module module.map for libc++ (other than issues with my system headers). llvm-svn: 193219
OpenPOWER on IntegriCloud