summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* 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-071-11/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Implement final resolution of DR1402: implicitly-declared move operators thatRichard Smith2013-11-041-2/+2
| | | | | | | | | | | 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
* [-fms-extensions] Permit 'override' in C++98 and 'sealed' as a synonym for ↵David Majnemer2013-10-181-0/+6
| | | | | | | | | | | | | | 'final' Summary: Some MS headers use these features. Reviewers: rnk, rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1948 llvm-svn: 192936
* Convert anachronistic use of 'void *' to 'DeclContext *' in Scope that was a ↵Ted Kremenek2013-10-081-1/+1
| | | | | | holdover from the long-dead Action interface. llvm-svn: 192203
* Implement C++1y sized deallocation (n3778). This is not enabled by -std=c++1y;Richard Smith2013-09-291-55/+139
| | | | | | | instead, it's enabled by the -cc1 flag -fsized-deallocation, until we sort out the backward-compatibility issues. llvm-svn: 191629
* PR16529: Don't forget to add the CXXFunctionalCastExpr type sugar to anRichard Smith2013-09-231-8/+11
| | | | | | | InitListExpr for a C++11-style T{...} construction, if initialization registered a destructor for it. llvm-svn: 191182
* Avoid getting an argument of allocation function if it does not exist.Serge Pavlov2013-09-141-11/+12
| | | | | | | | This is a fix to PR12778: in erroneous code an allocation function can be declared with no arguments, quering the first argument in this case causes assertion violation. llvm-svn: 190751
OpenPOWER on IntegriCloud