summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Now that ASTMultiPtr is nothing more than a array reference, make it a ↵Benjamin Kramer2012-08-231-16/+11
| | | | | | | | MutableArrayRef. This required changing all get() calls to data() and using the simpler constructors. llvm-svn: 162501
* Rip out remnants of move semantic emulation and smart pointers in Sema.Benjamin Kramer2012-08-231-15/+14
| | | | | | | These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
* Don't do jump-scope checking when code completion is enabled. It'sDouglas Gregor2012-08-171-1/+2
| | | | | | | | both a waste of time, and prone to crash due to the use of the error-recovery path in parser. Fixes <rdar://problem/12103608>, which has been driving me nuts. llvm-svn: 162081
* Implement warning for integral null pointer constants other than the literal 0.David Blaikie2012-08-081-1/+4
| | | | | | | | | | | | | | | | | | | | This is effectively a warning for code that violates core issue 903 & thus will become standard error in the future, hopefully. It catches strange null pointers such as: '\0', 1 - 1, const int null = 0; etc... There's currently a flaw in this warning (& the warning for 'false' as a null pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0' for example). Fix to come in a future patch. Also, due to this only being a warning, not an error, it triggers quite frequently on gtest code which tests expressions for null-pointer-ness in a SFINAE context (so it wouldn't be a problem if this was an error as in an actual implementation of core issue 903). To workaround this for now, the diagnostic does not fire in unevaluated contexts. Review by Sean Silva and Richard Smith. llvm-svn: 161501
* objc: Include all types when issuing warning underFariborz Jahanian2012-08-081-5/+4
| | | | | | -Wdirect-ivar-access. llvm-svn: 161500
* objc-arc: Make -Wdirect-ivar-access accessible to allFariborz Jahanian2012-08-071-3/+1
| | | | | | | memory models, except when arc is accessing a weak ivar (which is an error). // rdar://6505197 llvm-svn: 161458
* objective-c: Exclude -Wdirect-ivar-access for arc.Fariborz Jahanian2012-08-071-2/+6
| | | | | | | Allow direct ivar access in init and dealloc methods in mrr. // rdar://650197 llvm-svn: 161426
* objective-c: Implement gcc's -Wdirect-ivar-access option.Fariborz Jahanian2012-08-061-0/+3
| | | | | | // rdar://6505197 llvm-svn: 161362
* Refactor checks for unevaluated contexts into a common utility function.David Blaikie2012-08-061-4/+3
| | | | | | | | | The one caller that's surrounded by nearby code manipulating the underlying evaluation context list is left unmodified for readability. Review by Sean Silva and Richard Smith. llvm-svn: 161355
* Introduce new queries on ObjCRuntime for how to interpret subscriptsJohn McCall2012-07-311-55/+75
| | | | | | | | on object pointers and whether pointer arithmetic on object pointers is supported. Make ObjFW interpret subscripts as pseudo-objects. Based on a patch by Jonathan Schleifer. llvm-svn: 161028
* Final piece of core issue 1330: delay computing the exception specification ofRichard Smith2012-07-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
* PR12917: Remove incorrect assumption that lambda mangling information cannotRichard Smith2012-07-221-0/+3
| | | | | | | | | | change once it's been assigned. It can change in two ways: 1) In a template instantiation, the context declaration should be the instantiated declaration, not the declaration in the template. 2) If a lambda appears in the pattern of a variadic pack expansion, the mangling number will depend on the pack length. llvm-svn: 160614
* For varargs, diagnose passing ObjC objects by value like other non-POD types.Jordan Rose2012-07-191-11/+16
| | | | | | | | | | | | | | While we still want to consider this a hard error (non-POD variadic args are normally a DefaultError warning), delaying the diagnostic allows us to give better error messages, which also match the usual non-POD errors more closely. In addition, this change improves the diagnostic messages for format string argument type mismatches by passing down the type of the callee, so we can say "variadic method" or "variadic function" appropriately. <rdar://problem/11825593> llvm-svn: 160517
* Handle the case where the base type is not dependent, but the derived one is.Rafael Espindola2012-07-171-2/+0
| | | | | | Fixes pr13353.cpp. llvm-svn: 160393
* Issue warning when assigning out-of-range integer values to enums.Fariborz Jahanian2012-07-171-1/+4
| | | | | | | Due to performance cost, this is an opt-in option placed under -Wassign-enum. // rdar://11824807 llvm-svn: 160382
* -Wobjc-literal-compare: don't warn when comparing against nil.Jordan Rose2012-07-171-2/+16
| | | | | | | | | | | | | | Checks against nil often appear as guards in macros, and comparing Objective-C literals to nil has well-defined behavior (if tautological). On OS X, 'nil' has not been typed as 'id' since 10.6 (possibly earlier), so the warning was already not firing, but other runtimes continue to use ((id)0) or some variant. This change accepts comparisons to any null pointer; to keep it simple, it looks through all casts (not just casts to 'id'). PR13276 llvm-svn: 160379
OpenPOWER on IntegriCloud