summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Add -Wobjc-string-compare under -Wobjc-literal-compare.Jordan Rose2012-07-171-9/+22
| | | | | | | | | Suggested by Ted, since string literal comparison is at least slightly more sensible than comparison of runtime literals. (Ambiguous language on developer.apple.com implies that strings are guaranteed to be uniqued within a translation unit and possibly across a linked binary.) llvm-svn: 160378
* Now that -Wobjc-literal-compare is a warning, put the fixit on a note.Jordan Rose2012-07-171-100/+66
| | | | | | | | Recovering as if the user had actually called -isEqual: is a bit too far from the semantics of the program as written, /even though/ it's probably what they intended. llvm-svn: 160377
* PR13365: Fix code which was trying to treat an array of DeducedTemplateArgumentRichard Smith2012-07-161-2/+3
| | | | | | | | as an array of its base class TemplateArgument. Switch the const TemplateArgument* parameters of InstantiatingTemplate's constructors to ArrayRef<TemplateArgument> to prevent this from happening again in the future. llvm-svn: 160245
* Downgrade the "direct comparison" error for ObjC literals to a warning.Jordan Rose2012-07-091-7/+17
| | | | | | | | | | | Chris pointed out that while the comparison is certainly problematic and does not have well-defined behavior, it isn't any worse than some of the other abuses that we merely warn about and doesn't need to make the compilation fail. Revert the release notes change (r159766) now that this is just a new warning. llvm-svn: 159939
* PR9793: Treat substitution as an instantiation step for the purpose of theRichard Smith2012-07-081-0/+2
| | | | | | | | -ftemplate-depth limit. There are various ways to get an infinite (or merely huge) stack of substitutions with no intervening instantiations. This is also consistent with gcc's behavior. llvm-svn: 159907
* Rename -Wself-assign-memvar to -Wself-assign-field to improve local ↵Nico Weber2012-07-031-8/+8
| | | | | | | | consistency a bit. (cf -Wunused-private-field and several other existing -field diagnostics.) llvm-svn: 159633
* In blocks, only pretend that enum constants have enum type if necessary.Jordan Rose2012-07-021-2/+10
| | | | | | | | | | | | | | | | | | In C, enum constants have the type of the enum's underlying integer type, rather than the type of the enum. (This is not true in C++.) Thus, when a block's return type is inferred from an enum constant, it is incompatible with expressions that return the enum type. In r158899, I told block returns to pretend that enum constants have enum type, like in C++. Doug Gregor pointed out that this can break existing code. Now, we don't check the types of return statements until the end of the block. This lets us go back and add implicit casts in blocks with mixed enum constants and enum-typed expressions. <rdar://problem/11662489> (again) llvm-svn: 159591
* Change condition to be the same as in SemaTemplateInstantiate.Nico Weber2012-06-291-1/+1
| | | | | | No functionality change. llvm-svn: 159436
* Warn on self-assignment to member variables. PR13104.Nico Weber2012-06-281-1/+24
| | | | llvm-svn: 159394
* Refactoring after r159290: don't hold onto and check a misleading QualType.Richard Smith2012-06-271-4/+3
| | | | llvm-svn: 159292
* Check for non-POD vararg argument type after default argument promotion, notRichard Smith2012-06-271-1/+1
| | | | | | before, so we don't incorrectly think arguments of function type are non-POD. llvm-svn: 159290
* Implement John McCall's review of r159212 other than the this pointer notRafael Espindola2012-06-271-2/+3
| | | | | | being updated. Will fix that in a second. llvm-svn: 159280
* Fix a crash I introduced in r159212.Rafael Espindola2012-06-271-0/+2
| | | | llvm-svn: 159279
* During codegen of a virtual call we would extract any casts in the expressionRafael Espindola2012-06-261-0/+16
| | | | | | | | to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
* Unrevert r158887, reverted in r158949, along with a fix for the bug whichRichard Smith2012-06-251-73/+101
| | | | | | | | | | | | | | | | | | | | resulted in it being reverted. A test for that bug was added in r158950. Original comment: If an object (such as a std::string) with an appropriate c_str() member function is passed to a variadic function in a position where a format string indicates that c_str()'s return type is desired, provide a note suggesting that the user may have intended to call the c_str() member. Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and move it to SemaChecking in order to facilitate this. Factor the call checking out of function call checking and block call checking, and extend it to cover constructor calls too. Patch by Sam Panzer! llvm-svn: 159159
* Support L__FUNCTION__ in microsoft mode, PR11789Nico Weber2012-06-231-1/+5
| | | | | | | | | | Heavily based on a patch from Aaron Wishnick <aaron.s.wishnick@gmail.com>. I'll clean up the duplicated function in CodeGen as a follow-up, later today or tomorrow. llvm-svn: 159060
* Show fixit for unqualified calls to methods of dependent basesNico Weber2012-06-221-28/+32
| | | | | | | | when the calling site is a member function template. Effectively reverts r111675. llvm-svn: 159004
* Revert r158887. This fixes pr13168.Rafael Espindola2012-06-211-101/+73
| | | | | | | | Revert "If an object (such as a std::string) with an appropriate c_str() member function" This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e. llvm-svn: 158949
* Don't warn for -Wstatic-in-inline if the used function is also inline.Jordan Rose2012-06-211-7/+15
| | | | | | | | | | | | | | | | | | Also, don't warn if the used function is __attribute__((const)), in which case it's not supposed to use global variables anyway. The inline-in-inline thing is a heuristic, and one that's possibly incorrect fairly often because the function being inlined could definitely use global variables. However, even some C standard library functions are written using other (trivial) static-inline functions in the headers, and we definitely don't want to be warning on that (or on anything that /uses/ these trivial inline functions). So we're using "inlined" as a marker for "fairly trivial". (Note that __attribute__((pure)) does /not/ guarantee safety like ((const), because ((const)) does not guarantee that global variables are not being used, and the warning is about globals not being shared across TUs.) llvm-svn: 158898
* If an object (such as a std::string) with an appropriate c_str() member functionRichard Smith2012-06-211-73/+101
| | | | | | | | | | | | | | | is passed to a variadic function in a position where a format string indicates that c_str()'s return type is desired, provide a note suggesting that the user may have intended to call the c_str() member. Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and move it to SemaChecking in order to facilitate this. Factor the call checking out of function call checking and block call checking, and extend it to cover constructor calls too. Patch by Sam Panzer! llvm-svn: 158887
* Allow unqualified lookup of non-dependent member functionsNico Weber2012-06-201-4/+2
| | | | | | | | | | in microsoft mode. Fixes PR12701. The code for this was already in 2 of the 3 branches of a conditional and missing in the 3rd branch, so lift it above the conditional. llvm-svn: 158842
* Remove -Winternal-linkage-in-inline in C++.Jordan Rose2012-06-201-58/+16
| | | | | | | | | | | | | | | | It's very easy for anonymous external linkage to propagate in C++ through return types and parameter types. Likewise, it's possible that a template containing an inline function is only used with parameters that have internal linkage. Actually diagnosing where the internal linkage comes from is fairly difficult (both to locate and then to print nicely). Finally, since we only have one translation unit available, we can't even prove that any of this violates the ODR. This warning needs better-defined behavior in C++ before it can really go in. Rewording of the C warning (which /is/ specified by C99) coming shortly. llvm-svn: 158836
* Restructure how the driver communicates information about theJohn McCall2012-06-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
* Change -Winternal-linkage-in-inline from ExtWarn to Warning in C++.Jordan Rose2012-06-181-8/+16
| | | | | | | | | | Per post-commit review, it's not appropriate to use ExtWarn in C++, because we can't prove that the inline function will actually be defined in more than one place (and thus we can't prove that this violates the ODR). This removes the warning entirely from uses in the main source file in C++. llvm-svn: 158689
* Support -Winternal-linkage-in-inline in C++ code.Jordan Rose2012-06-181-36/+98
| | | | | | | | This includes treating anonymous namespaces like internal linkage, and allowing const variables to be used even if internal. The whole thing's been broken out into a separate function to avoid nested ifs. llvm-svn: 158683
* Allow internal decls in inline functions if the function is in the main file.Jordan Rose2012-06-181-1/+7
| | | | | | | | | | | This handles the very common case of people writing inline functions in their main source files and not tagging them as inline. These cases should still behave as the user intended. (The diagnostic is still emitted as an extension.) I'm reworking this code anyway to account for C++'s equivalent restriction in [basic.def.odr]p6, but this should get some bots back to green. llvm-svn: 158666
* Fix Sema and IRGen for atomic compound assignment so it has the right ↵Eli Friedman2012-06-161-45/+20
| | | | | | | | semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
* Warn when a static variable is referenced in a non-static inline function.Jordan Rose2012-06-151-0/+32
| | | | | | | | | | | | | This is explicitly forbidden in C99 6.7.4p3. This is /not/ forbidden in C++, probably because by default file-scope const/constexpr variables have internal linkage, while functions have external linkage. There's also the issue of anonymous namespaces to consider. Nevertheless, there should probably be a similar warning, since the semantics of inlining a function that references a variable with internal linkage do not seem well-defined. <rdar://problem/11577619> llvm-svn: 158531
* Check the parameter lists and return type of both blocks and lambdasDouglas Gregor2012-06-151-1/+14
| | | | | | | for unexpanded parameter packs. Fixes the crash-on-invalid in PR13117. llvm-svn: 158525
* PR13064: Store whether an in-class initializer uses direct or copyRichard Smith2012-06-101-1/+1
| | | | | | | initialization, and use that information to produce the right kind of initialization during template instantiation. llvm-svn: 158288
* Disallow using ObjC literals in direct comparisons (== and friends).Jordan Rose2012-06-081-0/+157
| | | | | | | | | | | | | | | Objective-C literals conceptually always create new objects, but may be optimized by the compiler or runtime (constant folding, singletons, etc). Comparing addresses of these objects is relying on this optimization behavior, which is really an implementation detail. In the case of == and !=, offer a fixit to a call to -isEqual:, if the method is available. This fixit is directly on the error so that it is automatically applied. Most of the time, this is really a newbie mistake, hence the fixit. llvm-svn: 158230
* Plug a long standing memory leak in TemplateArgument.Benjamin Kramer2012-06-071-1/+1
| | | | | | | | | | | | | | | The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
OpenPOWER on IntegriCloud