summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it.Richard Smith2012-04-171-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
* Implement C++11 [expr.prim.general]p3, which permits the use of 'this'Douglas Gregor2012-04-161-11/+49
| | | | | | | | | | | | | | | | | | | | | | | in the declaration of a non-static member function after the (optional) cv-qualifier-seq, which in practice means in the exception specification and late-specified return type. The new scheme here used to manage 'this' outside of a member function scope is more general than the Scope-based mechanism previously used for non-static data member initializers and late-parsesd attributes, because it can also handle the cv-qualifiers on the member function. Note, however, that a separate pass is required for static member functions to determine whether 'this' was used, because we might not know that we have a static function until after declaration matching. Finally, this introduces name mangling for 'this' and for the implicit 'this', which is intended to match GCC's mangling. Independent verification for the new mangling test case would be appreciated. Fixes PR10036 and PR12450. llvm-svn: 154799
* Fix some i1/i8 confusion within _Atomic(bool) in IR generation, bothDouglas Gregor2012-04-121-0/+7
| | | | | | | | | | | | | | in general (such an atomic has boolean representation) and specifically for IR generation of __c11_atomic_init. The latter also means actually using initialization semantics for this initialization, rather than just creating a store. On a related note, make sure we actually put in non-atomic-to-atomic conversions when performing an implicit conversion sequence. IR generation is far too kind here, but we still want the ASTs to make sense. llvm-svn: 154612
* Fix several problems with protected access control:John McCall2012-04-071-2/+3
| | | | | | | | | | | | | | | | | | | | | - The [class.protected] restriction is non-trivial for any instance member, even if the access lacks an object (for example, if it's a pointer-to-member constant). In this case, it is equivalent to requiring the naming class to equal the context class. - The [class.protected] restriction applies to accesses to constructors and destructors. A protected constructor or destructor can only be used to create or destroy a base subobject, as a direct result. - Several places were dropping or misapplying object information. The standard could really be much clearer about what the object type is supposed to be in some of these accesses. Usually it's easy enough to find a reasonable answer, but still, the standard makes a very confident statement about accesses to instance members only being possible in either pointer-to-member literals or member access expressions, which just completely ignores concepts like constructor and destructor calls, using declarations, unevaluated field references, etc. llvm-svn: 154248
* PR10217: Provide diagnostics explaining why an implicitly-deleted specialRichard Smith2012-03-301-2/+1
| | | | | | member function is deleted. llvm-svn: 153773
* Unify naming of LangOptions variable/get function across the Clang stack ↵David Blaikie2012-03-111-26/+26
| | | | | | | | | | (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
* Fix crash & accepts-invalid for array of arrays of user defined type.David Blaikie2012-03-101-8/+11
| | | | | | | Test case/other help by Richard Smith. Code review by John McCall. llvm-svn: 152519
* Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr toJohn McCall2012-03-101-0/+1
| | | | | | | | track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of this bit. llvm-svn: 152491
* [Sema] Fix a diag change to include a range that appeared intended, but neverDaniel Dunbar2012-03-091-1/+2
| | | | | | actually happened. llvm-svn: 152442
* [Sema] Remove dead getSourceRange() call, caught by Clang after markingDaniel Dunbar2012-03-091-2/+1
| | | | | | LLVM_READONLY. llvm-svn: 152428
* [AST/Sema/libclang] Replace getSourceRange().getBegin() with getLocStart().Daniel Dunbar2012-03-091-13/+13
| | | | | | | | | - getSourceRange().getBegin() is about as awesome a pattern as .copy().size(). I already killed the hot paths so this doesn't seem to impact performance on my tests-of-the-day, but it is a much more sensible (and shorter) pattern. llvm-svn: 152419
* Perform l2r conversions on delete operands before doingJohn McCall2012-03-091-3/+3
| | | | | | | type-analysis; otherwise, we just completely do the wrong thing for placeholders. llvm-svn: 152375
* Add clang support for new Objective-C literal syntax for NSDictionary, NSArray,Ted Kremenek2012-03-061-9/+18
| | | | | | | | | | | | | NSNumber, and boolean literals. This includes both Sema and Codegen support. Included is also support for new Objective-C container subscripting. My apologies for the large patch. It was very difficult to break apart. The patch introduces changes to the driver as well to cause clang to link in additional runtime support when needed to support the new language features. Docs are forthcoming to document the implementation and behavior of these features. llvm-svn: 152137
* If the element type of an initializer list has a destructor, make sure we ↵Sebastian Redl2012-03-051-2/+1
| | | | | | check it. Fixes PR12178. llvm-svn: 152048
* Implement "optimization" for lambda-to-block conversion which inlines the ↵Eli Friedman2012-03-011-5/+37
| | | | | | | | generated block literal for lambdas which are immediately converted to block pointer type. This simplifies the AST, avoids an unnecessary copy of the lambda and makes it much easier to avoid copying the result onto the heap. Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed. llvm-svn: 151797
* Tighten type-checking a bit to make it clearer how BuildCXXMemberCallExpr is ↵Eli Friedman2012-03-011-2/+3
| | | | | | used. llvm-svn: 151783
* Make sure list-initialization of arrays works correctly in explicit type ↵Eli Friedman2012-02-291-14/+18
| | | | | | conversions. PR12121. llvm-svn: 151674
* Ensure that we delete destructors in the right cases. Specifically:Richard Smith2012-02-261-4/+10
| | | | | | | | | | | | | | - variant members with nontrivial destructors make the containing class's destructor deleted - check for a virtual destructor after checking for overridden methods in the base class(es) - check for an inaccessible operator delete for a class with a virtual destructor. Do not try to call an anonymous union field's destructor from the destructor of the containing class. llvm-svn: 151483
* ArrayRef'ize various functions in the AST/Parser/Sema.Ahmed Charles2012-02-251-8/+16
| | | | llvm-svn: 151447
* Fix assertion (too few Diag arguments) when diagnosing a deleted operator deleteRichard Smith2012-02-251-1/+2
| | | | llvm-svn: 151442
* Fix comment: correct predicate name, reformat comment.Dmitri Gribenko2012-02-241-5/+4
| | | | llvm-svn: 151389
* Implement a new type trait __is_trivially_constructible(T, Args...)Douglas Gregor2012-02-241-0/+121
| | | | | | | | | | | | | | | | that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
* Provide the __is_trivially_assignable type trait, which providesDouglas Gregor2012-02-231-0/+49
| | | | | | | compiler support for the std::is_trivially_assignable library type trait. llvm-svn: 151240
* Throw away stray CXXDefaultArgExprs. Fixes PR12061.Sebastian Redl2012-02-221-0/+7
| | | | | | I think there's a deeper problem here in the way TransformCXXConstructExpr works, but I won't tackle it now. llvm-svn: 151146
* Implement C++11 [expr.call]p11: If the operand to a decltype-specifier is aRichard Smith2012-02-221-8/+104
| | | | | | | | | | | | | | | | | | function call (or a comma expression with a function call on its right-hand side), possibly parenthesized, then the return type is not required to be complete and a temporary is not bound. Other subexpressions inside a decltype expression do not get this treatment. This is implemented by deferring the relevant checks for all calls immediately within a decltype expression, then, when the expression is fully-parsed, checking the relevant constraints and stripping off any top-level temporary binding. Deferring the completion of the return type exposed a bug in overload resolution where completion of the argument types was not attempted, which is also fixed by this change. llvm-svn: 151117
* Emit a warning when list-initializing a std::initializer_list member.Sebastian Redl2012-02-191-1/+1
| | | | llvm-svn: 150933
* Rewrite variable capture within lambda expressions and blocks,Douglas Gregor2012-02-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eliminating a bunch of redundant code and properly modeling how the captures of outside blocks/lambdas affect the types seen by inner captures. This new scheme makes two passes over the capturing scope stack. The first pass goes up the stack (from innermost to outermost), assessing whether the capture looks feasible and stopping when it either hits the scope where the variable is declared or when it finds an existing capture. The second pass then walks down the stack (from outermost to innermost), capturing the variable at each step and updating the captured type and the type that an expression referring to that captured variable would see. It also checks type-specific restrictions, such as the inability to capture an array within a block. Note that only the first odr-use of each variable needs to do the full walk; subsequent uses will find the capture immediately, so multiple walks need not occur. The same routine that builds the captures can also compute the type of the captures without signaling errors and without actually performing the capture. This functionality is used to determine the type of declaration references as well as implementing the weird decltype((x)) rule within lambda expressions. The capture code now explicitly takes sides in the debate over C++ core issue 1249, which concerns the type of captures within nested lambdas. We opt to use the more permissive, more useful definition implemented by GCC rather than the one implemented by EDG. llvm-svn: 150875
* Add a bunch of missing calls to DiagnoseSentinelCalls. ↵Eli Friedman2012-02-181-0/+5
| | | | | | | | <rdar://problem/10885993>. This should probably be refactored... but it isn't completely obvious what refactoring is best. llvm-svn: 150869
* Diagnose uses of deleted destructors and inaccessible defaulted destructors.Richard Smith2012-02-181-8/+15
| | | | | | | | | | We had two separate issues here: firstly, varions functions were assuming that they did not need to perform semantic checks on trivial destructors (this is not true in C++11, where a trivial destructor can nonetheless be private or deleted), and a bunch of DiagnoseUseOfDecl calls were missing for uses of destructors. llvm-svn: 150866
* Don't allow non-empty ParenListExprs as array-new initializers.Sebastian Redl2012-02-171-5/+2
| | | | | | Don't know what I was thinking there. Fixes PR12023. llvm-svn: 150804
* Proper checking of list-initializers for array new expressions.Sebastian Redl2012-02-161-9/+28
| | | | | | This finishes generalized initializer support in Sema. llvm-svn: 150688
* Revert "Revert "Make CXXNewExpr contain only a single initialier, and not ↵Sebastian Redl2012-02-161-84/+92
| | | | | | | | hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
* Revert "Make CXXNewExpr contain only a single initialier, and not hold the ↵Sebastian Redl2012-02-161-92/+84
| | | | | | | | | | used constructor itself." It leads to a compiler crash in the Bullet benchmark. This reverts commit r12014. llvm-svn: 150684
* Make CXXNewExpr contain only a single initialier, and not hold the used ↵Sebastian Redl2012-02-161-84/+92
| | | | | | | | | | constructor itself. Holding the constructor directly makes no sense when list-initialized arrays come into play. The constructor is now held in a CXXConstructExpr, if construction is what is done. The new design can also distinguish properly between list-initialization and direct-initialization, as well as implicit default-initialization constructors and explicit value-initialization constructors. Finally, doing it this way removes redundance from the AST because CXXNewExpr doesn't try to handle both the allocation and the initialization responsibilities. This breaks the static analysis of new expressions. I've filed PR12014 to track this. llvm-svn: 150682
* Don't route explicit construction via list-initialization through the ↵Sebastian Redl2012-02-131-3/+18
| | | | | | functional cast code path. It sometimes does the wrong thing, produces horrible error messages, and is just unnecessary. llvm-svn: 150408
* Proper initializer list support for new expressions and type construct ↵Sebastian Redl2012-02-121-14/+50
| | | | | | expressions. Array new still missing. llvm-svn: 150346
* Make sure Sema creates a field for 'this' captures. (Doug, please ↵Eli Friedman2012-02-111-1/+15
| | | | | | double-check that this is correct.) llvm-svn: 150292
* Allow implicit capture of 'this' in a lambda even when the captureDouglas Gregor2012-02-101-2/+1
| | | | | | | | | | | | default is '=', and reword the warning about explicitly capturing 'this' in such lambdas to indicate that only explicit capture is banned. Introduce Fix-Its for this and other "save the programmer from themself" rules regarding what can be explicitly captured and what must be implicitly captured. llvm-svn: 150256
* Factor C++11 lambda expressions implementation into a separateDouglas Gregor2012-02-081-330/+0
| | | | | | file. No functionality change. llvm-svn: 150089
* When completing a lambda expression, make sure to check and attach theDouglas Gregor2012-02-081-13/+19
| | | | | | body of the lambda to the function call operator. llvm-svn: 150087
* Introduce basic ASTs for lambda expressions. This covers:Douglas Gregor2012-02-071-4/+77
| | | | | | | | | | | | | | | | | | | | | | | | - Capturing variables by-reference and by-copy within a lambda - The representation of lambda captures - The creation of the non-static data members in the lambda class that store the captured variables - The initialization of the non-static data members from the captured variables - Pretty-printing lambda expressions There are a number of FIXMEs, both explicit and implied, including: - Creating a field for a capture of 'this' - Improved diagnostics for initialization failures when capturing variables by copy - Dealing with temporaries created during said initialization - Template instantiation - AST (de-)serialization - Binding and returning the lambda expression; turning it into a proper temporary - Lots and lots of semantic constraints - Parameter pack captures llvm-svn: 149977
* Added location for template keyword in TemplateSpecializationTypeLoc. In the ↵Abramo Bagnara2012-02-061-0/+2
| | | | | | process removed some naming ambiguities. llvm-svn: 149870
* In C++11 mode, when an integral constant expression is desired and we have aRichard Smith2012-02-041-15/+15
| | | | | | | | | | | | | | | | | | value of class type, look for a unique conversion operator converting to integral or unscoped enumeration type and use that. Implements [expr.const]p5. Sema::VerifyIntegerConstantExpression now performs the conversion and returns the converted result. Some important callers of Expr::isIntegralConstantExpr have been switched over to using it (including all of those required for C++11 conformance); this switch brings a side-benefit of improved diagnostics and, in several cases, simpler code. However, some language extensions and attributes have not been moved across and will not perform implicit conversions on constant expressions of literal class type where an ICE is required. In passing, fix static_assert to perform a contextual conversion to bool on its argument. llvm-svn: 149776
* Don't allow a value of a scoped enumeration to be used as the first bound for anRichard Smith2012-02-041-4/+8
| | | | | | | array new expression. This lays some groundwork for the implicit conversion to integral or unscoped enumeration which C++11 ICEs undergo. llvm-svn: 149772
* Fix a rejects-valid in C++11: array new of a negative size, or overflowing arrayRichard Smith2012-02-041-16/+32
| | | | | | | | | | | | | | | | | new, is well-formed with defined semantics of throwing (a type which can be caught by a handler for) std::bad_array_new_length, unlike in C++98 where it is somewhere nebulous between undefined behavior and ill-formed. If the array size is an integral constant expression and satisfies one of these criteria, we would previous the array new expression, but now in C++11 mode, we merely issue a warning (the code is still rejected in C++98 mode, naturally). We don't yet implement new C++11 semantics correctly (see PR11644), but we do implement the overflow checking, and (for the default operator new) convert such expressions to an exception, so accepting such code now does not seem especially unsafe. llvm-svn: 149767
* Don't warn on use of default allocator with an over-aligned type when theNick Lewycky2012-02-041-1/+1
| | | | | | allocator is given the pointer to allocate into. llvm-svn: 149760
* Clang has existing support for debuggers thatSean Callanan2012-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | want to provide "po"-like functionality which treats the result of an expression implicitly as "id" (if it is not otherwise known) and prints it as an Objective-C object. This has in the past been gated by the "DebuggerSupport" language option, but that is too general. Debuggers also provide other commands like "print" that do not make any assumptions about whether the object is an Objective-C object. This patch makes the assumption conditional on a new language option: DebuggerCastResultToId. I have also made corresponding modifications to the testsuite. llvm-svn: 149735
* Make explicit captures which cause implicit captures work correctly.Eli Friedman2012-02-031-13/+4
| | | | llvm-svn: 149719
* Implement implicit capture for lambda expressions.Eli Friedman2012-02-031-1/+2
| | | | | | Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases. llvm-svn: 149718
* Note whether a lambda is mutable in the LambdaScopeInfo; this information ↵Eli Friedman2012-02-031-0/+2
| | | | | | will be necessary to handle references to captured variables. llvm-svn: 149660
OpenPOWER on IntegriCloud