summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Tweak Sema::CheckLiteralKind() to also include block literalsTed Kremenek2012-12-211-0/+3
| | | | | | | This simplifies some diagnostic logic in checkUnsafeAssignLiteral(), hopefully making it less error prone. llvm-svn: 170945
* Change checkUnsafeAssignLiteral() to use the new Sema::CheckLiteralKind().Ted Kremenek2012-12-211-1/+1
| | | | | | | | | | Along the way, fix a bug in CheckLiteralKind(), previously in diagnoseObjCLiteralComparison, where we didn't ignore parentheses in boxed expressions for purpose of classification. In other words, both @42 and @(42) should be classified as numeric literals. llvm-svn: 170931
* Hoist logic for classifying Objective-C literals into Sema (proper) for use ↵Ted Kremenek2012-12-211-52/+45
| | | | | | | | with other diagnostics. No immediate (intended) functionality change. llvm-svn: 170930
* Remove duplicate includes.Roman Divacky2012-12-211-1/+0
| | | | llvm-svn: 170903
* Fix regression in r170489: when instantiating a direct initializer which is aRichard Smith2012-12-211-1/+0
| | | | | | | | CXXScalarValueInitExpr (or an ImplicitValueInitExpr), strip it back down to an empty pair of parentheses so that the initialization code can tell that we're performing value-initialization. llvm-svn: 170867
* Sema: Don't emit a warning when __func__ is used in a lambda outside of a ↵Benjamin Kramer2012-12-061-2/+8
| | | | | | | | function. Fixes PR14518. llvm-svn: 169510
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-8/+8
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Fix the determination of whether a capture refers to an enclosingDouglas Gregor2012-12-011-3/+4
| | | | | | scope when dealing with nested blocks. Fixes <rdar://problem/12778708>. llvm-svn: 169065
* Merge function types in C.Rafael Espindola2012-11-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Among other differences, GCC accepts typedef int IA[]; typedef int A10[10]; static A10 *f(void); static IA *f(void); void g(void) { (void)sizeof(*f()); } but clang used to reject it with: invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []') The intention of c99's 6.2.7 seems to be that we should use the composite type and accept as gcc does. Doing the type merging required some extra fixes: * Use the type from the function type in initializations, even if an parameter is available. * Fix the merging of the noreturn attribute in function types. * Make CodeGen handle the fact that an parameter type can be different from the corresponding type in the function type. llvm-svn: 168895
* Reject uses of __int128 on platforms that don't support it. Also move the uglyRichard Smith2012-11-291-2/+6
| | | | | | | 'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be properly cleaned up. llvm-svn: 168856
* objective-C arc: load of a __weak object happens via call toFariborz Jahanian2012-11-271-0/+6
| | | | | | | | | | | objc_loadWeak. This retains and autorelease the weakly-refereced object. This hidden autorelease sometimes makes __weak variable alive even after the weak reference is erased, because the object is still referenced by an autorelease pool. This patch overcomes this behavior by loading a weak object via call to objc_loadWeakRetained(), followng it by objc_release at appropriate place, thereby removing the hidden autorelease. // rdar://10849570 llvm-svn: 168740
* A step towards sorting out handling of triviality of special members in C++11.Richard Smith2012-11-161-6/+6
| | | | | | | | | | | | | | Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
* Fix DiagnoseBitwisePrecedence so it doesn't cast "-1" to the typeEli Friedman2012-11-151-24/+16
| | | | | | | | | BinaryOperator::Opcode. This is bad form, and the behavior of the static_cast in this case is unspecified according to the standard. Fixes a warning that showed up from r167992 on self-host. llvm-svn: 168010
* s/tranform/transform/Benjamin Kramer2012-11-141-3/+3
| | | | llvm-svn: 167929
* Accept and pass arguments to __unknown_anytype in argumentJohn McCall2012-11-141-0/+16
| | | | | | | | | | | | | | | | | | | | | positions of Objective-C methods. It is possible to recover a lot of type information about Objective-C methods from the reflective metadata for their implementations. This information is not rich when it comes to struct types, however, and it is not possible to produce a type in the debugger's round-tripped AST which will really do anything useful during type-checking. Therefore we allow __unknown_anytype in these positions, which essentially disables type-checking for that argument. We infer the parameter type to be the unqualified type of the argument expression unless that expression is an explicit cast, in which case it becomes the type-as-written of that cast. rdar://problem/12565338 llvm-svn: 167896
* -Wobjc-literal-compare: look through implicit casts.Jordan Rose2012-11-091-1/+2
| | | | | | | | | This warning was failing to fire under ARC because of the implicit lifetime casts added around the object literal expression. <rdar://problem/11300873>, again. llvm-svn: 167648
* PR11851 (and duplicates): Whenever a constexpr function is referenced,Richard Smith2012-11-071-9/+38
| | | | | | | | | instantiate it if it can be instantiated and implicitly define it if it can be implicitly defined. This matches g++'s approach. Remove some cases from SemaOverload which were marking functions as referenced when just planning how overload resolution would proceed; such cases are not actually references. llvm-svn: 167514
* When rebuilding a DependentScopeDeclRefExpr, perform a lookup into the scopeRichard Smith2012-10-231-2/+6
| | | | | | even if it's dependent, in case it now names a member of the current instantiation. llvm-svn: 166496
* Unrevert r166268, reverted in r166272, with a fix for the issue which NickRichard Smith2012-10-211-2/+12
| | | | | | | | | | | | | | | | | | | | | found: if an overloaded operator& is present before a template definition, the expression &T::foo is represented as a CXXOperatorCallExpr, not as a UnaryOperator, so we didn't notice that it's permitted to reference a non-static data member of an unrelated class. While investigating this, I discovered another problem in this area: we are treating template default arguments as unevaluated contexts during substitution, resulting in performing incorrect checks for uses of non-static data members in C++11. That is not fixed by this patch (I'll look into this soon; it's related to the failure to correctly instantiate constexpr function templates), but was resulting in this bug not firing in C++11 mode (except with -Wc++98-compat). Original message: PR14124: When performing template instantiation of a qualified-id outside of a class, diagnose if the qualified-id instantiates to a non-static class member. llvm-svn: 166385
* Fix __builtin_va_arg assertion failure in ARM AAPCS.Logan Chien2012-10-201-0/+10
| | | | llvm-svn: 166369
* DR1472: A reference isn't odr-used if it has preceding initialization,Richard Smith2012-10-201-9/+10
| | | | | | | | | initialized by a reference constant expression. Our odr-use modeling still needs work here: we don't yet implement the 'set of potential results of an expression' DR. llvm-svn: 166361
* Clarify wording of -Wshift-op-parentheses.David Blaikie2012-10-191-5/+5
| | | | | | Suggestion from Matt Beaumont-Gay reviewing r165283. llvm-svn: 166296
* Revert r166268, this fix for a crash-on-invalid introduced a rejects-valid.Nick Lewycky2012-10-191-12/+2
| | | | | | Richard has an unreduced testcase to work with. llvm-svn: 166272
* PR14124: When performing template instantiation of a qualified-id outside of aRichard Smith2012-10-191-2/+12
| | | | | | class, diagnose if the qualified-id instantiates to a non-static class member. llvm-svn: 166268
* Minor tweak to last patch along with a test case.Fariborz Jahanian2012-10-161-1/+1
| | | | | | // rdar://12491143 llvm-svn: 166030
* fixes an objc crash involving objc bool literal onFariborz Jahanian2012-10-161-1/+1
| | | | | | | hopelessly poorly written code after spewing several errors. // rdar://12491143 llvm-svn: 166025
* Un-revert r164907 and r164902 (+ follow-ups), 10.6 build fix to follow.Daniel Dunbar2012-10-151-6/+2
| | | | llvm-svn: 165988
* Revert r164907 and r164902 (+ follow-ups). They broke building on 10.6.Nico Weber2012-10-151-2/+6
| | | | | | See PR14013. llvm-svn: 165962
* Fix typo correction of one qualified name to another.David Blaikie2012-10-121-1/+2
| | | | | | | | | | | | | | When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken. This corrects that replacement in as many places as I could find & provides test cases for all those cases I could find a test case for. There are a couple that don't seem to be reachable (one looks entirely dead, the other just doesn't seem to ever get called with a namespace to namespace change). Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ). llvm-svn: 165817
* Provide a fixit when taking the address of an unqualified member function.David Blaikie2012-10-111-2/+10
| | | | | | | | | | | | | This only applies if the type has a name. (we could potentially do something crazy with decltype in C++11 to qualify members of unnamed types but that seems excessive) It might be nice to also suggest a fixit for "&this->i", "&foo->i", and "&foo.i" but those expressions produce 'bound' member functions that have a different AST representation & make error recovery a little trickier. Left as future work. llvm-svn: 165763
* Move Sema::PropertyIfSetterOrGetter to ObjCMethodDecl::findPropertyDecl.Jordan Rose2012-10-101-5/+9
| | | | | | | | Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl (the latter by name) over to findPropertyDecl. This actually makes -Wreceiver-is-weak a bit stronger than it was before. llvm-svn: 165628
* Use a single note diagnostic for all the precedent/parentheses warnings.David Blaikie2012-10-081-8/+10
| | | | llvm-svn: 165384
* StringRef-ify Binary/UnaryOperator::getOpcodeStrDavid Blaikie2012-10-081-2/+2
| | | | llvm-svn: 165383
* Implement -Wshift-op-parentheses for: a << b + cDavid Blaikie2012-10-051-0/+21
| | | | | | | | | | | | This appears to be consistent with GCC's implementation of the same warning under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user defined type for compatibility with C++ stream IO. Otherwise suggest parentheses around the addition or subtraction subexpression. (this came up when MSVC was complaining (incorrectly, so far as I can tell) about a perceived violation of this within the LLVM codebase, PR14001) llvm-svn: 165283
* objective-C arc: Warn under arc about a use of an ivar inside a blockFariborz Jahanian2012-10-031-0/+3
| | | | | | | that doesn't have a 'self' as this implicitly captures 'self' and could create retain cycles. Provide fixit. // rdar://11194874 llvm-svn: 165133
* Add FP_CONTRACT support for clang.Lang Hames2012-10-021-2/+4
| | | | | | | | Clang will now honor the FP_CONTRACT pragma and emit LLVM fmuladd intrinsics for expressions of the form A * B + C (when they occur in a single statement). llvm-svn: 164989
* -Warc-repeated-use-of-weak: check ivars and variables as well.Jordan Rose2012-09-281-3/+25
| | | | | | | | | | Like properties, loading from a weak ivar twice in the same function can give you inconsistent results if the object is deallocated between the two loads. It is safer to assign to a strong local variable and use that. Second half of <rdar://problem/12280249>. llvm-svn: 164855
* Add a warning (off by default) for repeated use of the same weak property.Jordan Rose2012-09-281-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivating example: if (self.weakProp) use(self.weakProp); As with any non-atomic test-then-use, it is possible a weak property to be non-nil at the 'if', but be deallocated by the time it is used. The correct way to write this example is as follows: id tmp = self.weakProp; if (tmp) use(tmp); The warning is controlled by -Warc-repeated-use-of-receiver, and uses the property name and base to determine if the same property on the same object is being accessed multiple times. In cases where the base is more complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a Decl for some degree of uniquing and reports the problem under a subflag, -Warc-maybe-repeated-use-of-receiver. This gives a way to tune the aggressiveness of the warning for a particular project. The warning is not on by default because it is not flow-sensitive and thus may have a higher-than-acceptable rate of false positives, though it is less noisy than -Wreceiver-is-weak. On the other hand, it will not warn about some cases that may be legitimate issues that -Wreceiver-is-weak will catch, and it does not attempt to reason about methods returning weak values. Even though this is not a real "analysis-based" check I've put the bug emission code in AnalysisBasedWarnings for two reasons: (1) to run on every kind of code body (function, method, block, or lambda), and (2) to suggest that it may be enhanced by flow-sensitive analysis in the future. The second (smaller) half of this work is to extend it to weak locals and weak ivars. This should use most of the same infrastructure. Part of <rdar://problem/12280249> llvm-svn: 164854
* Fix an edge case of mangling involving the combination of a lambda and typeid.Eli Friedman2012-09-261-0/+8
| | | | | | | | | | | | | typeid (and a couple other non-standard places where we can transform an unevaluated expression into an evaluated expression) is special because it introduces an an expression evaluation context, which conflicts with the mechanism to compute the current lambda mangling context. PR12123. I would appreciate if someone would double-check that we get the mangling correct with this patch. llvm-svn: 164658
* Change the wording of the extension warning fromDmitri Gribenko2012-09-241-5/+9
| | | | | | | | | > 'long long' is an extension when C99 mode is not enabled to > 'long long' is a C++11 extension while compiling in C++98 mode. llvm-svn: 164545
* Small cleanup of literal semantic analysis: hiding 'char *' pointers behindDmitri Gribenko2012-09-241-9/+10
| | | | | | | StringRef makes code cleaner. Also, make the temporary buffer smaller: 512 characters is unreasonably large for integer literals. llvm-svn: 164484
* objective-C: when diagnosing deprecated/unavailable usage ofFariborz Jahanian2012-09-211-5/+19
| | | | | | | setter or getter backing a deprecated/unavailable property, also not location of the property. // rdar://12324295 llvm-svn: 164412
* -Warc-retain-cycles: warn at variable initialization as well as assignment.Jordan Rose2012-09-151-3/+11
| | | | | | | | | | | | | | | | | | Specifically, this should warn: __block block_t a = ^{ a(); }; Furthermore, this case which previously warned now does not, since the value of 'b' is captured before the assignment occurs: block_t b; // not __block b = ^{ b(); }; (This will of course warn under -Wuninitialized, as before.) <rdar://problem/11015883> llvm-svn: 163962
* In debugger mode, allow comparisons between pointers and integersDouglas Gregor2012-09-141-1/+4
| | | | | | without a cast. Fixes <rdar://problem/11830912>. llvm-svn: 163873
* refactoring + objective-C specific test for my last patch.Fariborz Jahanian2012-09-061-4/+1
| | | | | | // rdar://12233989 llvm-svn: 163338
* c: make __attribute__((unused)) transitive.Fariborz Jahanian2012-09-061-3/+13
| | | | | | | Don't warn if annotated decl is used inside another unused. // rdar://12233989 llvm-svn: 163329
* Change the representation of builtin functions in the ASTEli Friedman2012-08-311-3/+24
| | | | | | | | | (__builtin_* etc.) so that it isn't possible to take their address. Specifically, introduce a new type to represent a reference to a builtin function, and a new cast kind to convert it to a function pointer in the operand of a call. Fixes PR13195. llvm-svn: 162962
* objective-C: clang must implicitly convert Fariborz Jahanian2012-08-301-1/+13
| | | | | | | | | | | __objc_yes/__objc_no to (BOOL)1/(BOOL)0 when BOOL is declared; otherwise it resorts to default of 'signed char'. This is important to selecting the correct Numeric API numberWithBool: Can't have a clang test for this. Will checkin and executable llvm test. // rdar://12156616 llvm-svn: 162922
* objective-C: make -Widiomatic-parentheses workFariborz Jahanian2012-08-291-1/+3
| | | | | | | when assignment expression in conditional invloves property reference. // rdar://11066598 llvm-svn: 162846
* Push ArrayRef through the Expr hierarchy.Benjamin Kramer2012-08-241-48/+40
| | | | | | No functionality change. llvm-svn: 162552
OpenPOWER on IntegriCloud