summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Track the difference betweenRichard Smith2014-07-171-18/+15
| | | | | | | | | | | | -- a constructor list initialization that unpacked an initializer list into constructor arguments and -- a list initialization that created as std::initializer_list and passed it as the first argument to a constructor in the AST. Use this flag while instantiating templates to provide the right semantics for the resulting initialization. llvm-svn: 213224
* Remove llvm:: from uses of ArrayRef.Craig Topper2014-06-281-1/+1
| | | | llvm-svn: 211987
* [OPENMP] Loop canonical form analysis (Sema)Alexander Musman2014-06-031-1/+4
| | | | | | | | | This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form. This is the form required for 'omp simd', 'omp for' and other loop pragmas. Differential revision: http://reviews.llvm.org/D3778 llvm-svn: 210095
* Fix 'this' capturing Generic lambdas used within default initializers (PR19876) Faisal Vali2014-05-301-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | http://llvm.org/bugs/show_bug.cgi?id=19876 The following C++1y code results in a crash: struct X { int m = 10; int n = [this](auto) { return m; }(20); }; When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null. I considered two ways to fix this: 1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer. 2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type. I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1). Richard Smith accepted the patch: http://reviews.llvm.org/D3935 Thank you! llvm-svn: 209874
* Refactoring. Remove Owned method from Sema.Nikola Smiljanic2014-05-291-98/+79
| | | | llvm-svn: 209812
* Refactoring. Remove release and take methods from ActionResult. Rename ↵Nikola Smiljanic2014-05-291-84/+84
| | | | | | takeAs to getAs. llvm-svn: 209800
* [C++11] Use 'nullptr'. Sema edition.Craig Topper2014-05-261-77/+81
| | | | llvm-svn: 209613
* Sema: Implement DR244David Majnemer2014-05-211-16/+9
| | | | | | | | | | | | | | | | Summary: Naming the destructor using a typedef-name for the class-name is well-formed. This fixes PR19620. Reviewers: rsmith, doug.gregor Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3583 llvm-svn: 209319
* Push implicitly-declared allocation functions into the IdResolver. Otherwise,Richard Smith2014-05-161-3/+1
| | | | | | | declaration merging in modules is unable to find them and we get bogus errors and even crashes. llvm-svn: 208944
* Sema::FindAllocationFunctions(): Fix \param. [-Wdocumentation]NAKAMURA Takumi2014-05-141-1/+1
| | | | llvm-svn: 208758
* PR19729: Delete a bunch of bogus code in Sema::FindAllocationOverload. ThisRichard Smith2014-05-131-34/+24
| | | | | | | | | caused us to perform copy-initialization for the parameters of an allocation function called by a new-expression multiple times, resulting in us rejecting allocations that passed non-copyable parameters (and much worse things in MSVC compat mode, where we potentially called this function multiple times). llvm-svn: 208724
* Revert "Sema: Implement DR244"David Majnemer2014-05-031-3/+3
| | | | | | | | This was accidentally committed. This reverts commit r207892. llvm-svn: 207893
* Sema: Implement DR244David Majnemer2014-05-031-3/+3
| | | | | | | | | Naming the destructor using a typedef-name for the class-name is well-formed. This fixes PR19620. llvm-svn: 207892
* MSVCCompat: Don't produce an invalid AST when accepting void pseudo-dtorsReid Kleckner2014-05-011-2/+3
| | | | | | | | | | | | | We accept 'void *p; p->~void();' for MSVC compatibility since r148682. However, we were returning ExprError, rather than producing an AST, despite only diagnosing it with a warning. CodeGen noticed that the template function specialization had an invalid AST, and therefore didn't generate code for it. This change makes us produce an AST with a void pseudo-dtor call. Part of PR18256. llvm-svn: 207771
* Implement [over.match.oper]p3 properly, by filtering the non-candidates outRichard Smith2014-04-171-2/+3
| | | | | | | when building the candidate set, rather than trying to contort name lookup into handling this. llvm-svn: 206436
* PR19178 __is_constructible returns true for abstract types.Nikola Smiljanic2014-04-151-0/+5
| | | | llvm-svn: 206273
* DR1346: a parenthesized braced-init-list cannot be used as the initializer whenRichard Smith2014-03-121-3/+4
| | | | | | performing auto type deduction. llvm-svn: 203683
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-121-27/+29
| | | | | | class. llvm-svn: 203640
* PR18876: The special-case rule that ignores the destruction of a top-levelRichard Smith2014-02-181-3/+5
| | | | | | | | temporary in a decltype expression only applies if that temporary was created by a function call, not by a function-style cast or other flavour of expression. llvm-svn: 201542
* Fix lifetime issue causing buildbot failures.Richard Smith2014-02-081-2/+2
| | | | llvm-svn: 201012
* Fold together two repeated identical 'if's.Richard Smith2014-02-071-7/+5
| | | | llvm-svn: 201000
* Temporary fix for PR18473: Don't try to evaluate the initializer for aRichard Smith2014-02-061-7/+6
| | | | | | | | | | | | type-dependent variable, even if the initializer isn't value-dependent. This happens for ParenListExprs composed of non-value-dependent subexpressions, for instance. We should really give ParenListExprs (and InitListExprs) the type of the initialized entity if they're used to represent a dependent initialization (and if so, set them to be type-, value- and instantiation-dependent). llvm-svn: 200954
* Add implicit declarations of allocation functions when looking them up forRichard Smith2014-02-041-1/+3
| | | | | | | | redeclaration, not just when looking them up for a use -- we need the implicit declaration to appropriately check various properties of them (notably, whether they're deleted). llvm-svn: 200729
* Fix typo 'uusal'.Richard Smith2014-02-031-2/+2
| | | | llvm-svn: 200681
* PR17052 / DR1560 (+DR1550): In a conditional expression between a glvalue and aRichard Smith2014-01-271-34/+13
| | | | | | | throw-expression, the result is also a glvalue and isn't unnecessarily coerced to a prvalue. llvm-svn: 200189
* Rename getResultType() on function and method declarations to getReturnType()Alp Toker2014-01-251-1/+1
| | | | | | | | | | | | | | | A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
* Build an appropriate (albeit trivial) TypeSourceInfo for a destructor name, soRichard Smith2014-01-221-4/+11
| | | | | | | AST consumers can determine where the destructor name was written. Patch by Olivier Goffart! llvm-svn: 199779
* Rename FunctionProtoType accessors from 'arguments' to 'parameters'Alp Toker2014-01-201-4/+4
| | | | | | | | | | | | | | | | | Fix a perennial source of confusion in the clang type system: Declarations and function prototypes have parameters to which arguments are supplied, so calling these 'arguments' was a stretch even in C mode, let alone C++ where default arguments, templates and overloading make the distinction important to get right. Readability win across the board, especially in the casting, ADL and overloading implementations which make a lot more sense at a glance now. Will keep an eye on the builders and update dependent projects shortly. No functional change. llvm-svn: 199686
* MSVC 2013 type trait supportAlp Toker2014-01-201-19/+47
| | | | | | | | | | | | | | | | | | | | | 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
* Fix nothrow trait with multiple default constructorsAlp Toker2014-01-201-3/+7
| | | | | | | | | | | | | 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
* Fix string-literal to char* conversion in overload resolution for C++11Ismail Pazarbasi2014-01-171-2/+5
| | | | | | | | 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
* Distinguish between attributes explicitly written at the request of the ↵Aaron Ballman2014-01-161-3/+2
| | | | | | | | user, and attributes implicitly generated to assist in bookkeeping by the compiler. This is done so by table generating a CreateImplicit method for each attribute. Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it. llvm-svn: 199378
* Rename language option MicrosoftMode to MSVCCompatAlp Toker2014-01-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | There's been long-standing confusion over the role of these two options. This commit makes the necessary changes to differentiate them clearly, following up from r198936. MicrosoftExt (aka. fms-extensions): Enable largely unobjectionable Microsoft language extensions to ease portability. This mode, also supported by gcc, is used for building software like FreeBSD and Linux kernel extensions that share code with Windows drivers. MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode): Turn on a special mode supporting 'heinous' extensions for drop-in compatibility with the Microsoft Visual C++ product. Standards-compilant C and C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt. Note that full -fms-compatibility mode is currently enabled by default on the Windows target, which may need tuning to serve as a reasonable default. See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined type_info out of InitializePredefinedMacros' No change in behaviour. llvm-svn: 199209
* It turns out the problem was a bit more wide-spread. Removing a lot of ↵Aaron Ballman2014-01-031-1/+1
| | | | | | | | unneeded typecasts. getScopeRep() already returns a NestedNameSpecifier. No functional changes intended. llvm-svn: 198414
* Eliminate UnaryTypeTraitExprAlp Toker2014-01-011-33/+11
| | | | | | | | | | | | | Remove UnaryTypeTraitExpr and switch all remaining type trait related handling over to TypeTraitExpr. The UTT/BTT/TT enum prefix and evaluation code is retained pending further cleanup. This is part of the ongoing work to unify type traits following the removal of BinaryTypeTraitExpr in r197273. llvm-svn: 198271
* Don't reserve __builtin_types_compatible_p as a C++ keywordAlp Toker2013-12-251-10/+1
| | | | | | | | | 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
* Remove an unused parameter and include after r197273Alp Toker2013-12-131-2/+2
| | | | llvm-svn: 197274
* Eliminate BinaryTypeTraitExprAlp Toker2013-12-131-58/+31
| | | | | | | | | | | | | | | | | There's nothing special about type traits accepting two arguments. This commit eliminates BinaryTypeTraitExpr and switches all related handling over to TypeTraitExpr. Also fixes a CodeGen failure with variadic type traits appearing in a non-constant expression. The BTT/TT prefix and evaluation code is retained as-is for now but will soon be further cleaned up. This is part of the ongoing work to unify type traits. llvm-svn: 197273
* Unify type trait parsingAlp Toker2013-12-121-5/+1
| | | | | | | | | | | | | | | | | Type trait parsing is all over the place at the moment with unary, binary and n-ary C++11 type traits that were developed independently at different points in clang's history. There's no good reason to handle them separately -- there are three parsers, three AST nodes and lots of duplicated handling code with slightly different implementations and diags for each kind. This commit unifies parsing of type traits and sets the stage for further consolidation. No change in behaviour other than more consistent error recovery. llvm-svn: 197179
* PR17602: check accessibility when performing an implicit derived-to-baseRichard Smith2013-12-121-9/+10
| | | | | | | conversion on the LHS of a .* or ->*. Slightly improve diagnostics in case of an ambiguous base class. llvm-svn: 197125
* [REFACTOR] Refactored some of the generic-lambda capturing code.Faisal Vali2013-12-071-39/+61
| | | | | | | | | | | | | | | Employed the following refactorings: - Renamed some functions - Introduced explaining variables - Cleaned up & added comments - Used Optional<unsigned> for return value instead of an out parameter - Added assertions - Constified a few member functions No functionality change. All regressions pass. llvm-svn: 196662
* Tweak r196646Alp Toker2013-12-071-5/+3
| | | | | | | | | There was already a condition earlier in the function so just place the check there. Cleanup only. llvm-svn: 196647
* Type traits: No need for switch to handle __builtin_types_compatible_pAlp Toker2013-12-071-10/+4
| | | | | | | | | | | | __builtin_types_compatible_p() isn't a C++ type trait at all, rather a GNU C special-case, so it's fine to use BoolTy the default return type for binary type traits. This brings BTT in line with other arities that already default to BoolTy. Cleanup only, no change in behaviour. llvm-svn: 196646
* Fix code typos spotted while working on type traitsAlp Toker2013-12-061-2/+2
| | | | llvm-svn: 196587
* PR17983: Fix crasher bug in C++1y mode when performing a non-global arrayRichard Smith2013-12-051-3/+2
| | | | | | | delete on a class which has no array cookie and has no class-specific operator new. llvm-svn: 196488
* Fix init-captures for generic lambdas.Faisal Vali2013-12-051-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reject template-ids containing literal-operator-ids that have a dependentRichard Smith2013-12-051-0/+28
| | | | | | | | | 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
* Remove a whole lot of unused variablesAlp Toker2013-11-271-4/+2
| | | | | | | There are about 30 removed in this patch, generated by a new FixIt I haven't got round to submitting yet. llvm-svn: 195814
* COSMETIC: Fix 80 column overflow in some comments introduced in r194188Faisal Vali2013-11-121-7/+7
| | | | | | no functionality change. llvm-svn: 194449
* A quick fix to PR17877 that was introduced by r194188 ↵Faisal Vali2013-11-121-3/+18
| | | | | | | | | | | | | | | | (generic-lambda-capturing) that broke libc++. 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
OpenPOWER on IntegriCloud