summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/conversion.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.Chandler Carruth2016-12-201-1/+1
| | | | | | | | The latter agrees with most existing diagnostics and the C and C++ standards. Differential Revision: https://reviews.llvm.org/D26530 llvm-svn: 290159
* Make -Wnull-conversion more useful.Richard Trieu2016-02-131-0/+42
| | | | | | | | | | When a null constant is used in a macro, walk through the macro stack to determine where the null constant is written and where the context is located. Only warn if both locations are within the same macro expansion. This helps function-like macros which involve pointers be treated as if they were functions. llvm-svn: 260776
* Fix -Wnull-conversion for long macros.Richard Trieu2016-01-261-0/+28
| | | | | | | | | Move the function to get a macro name from DiagnosticRenderer.cpp to Lexer.cpp so that other files can use it. Lexer now has two functions to get the immediate macro name, the newly added one is better for diagnostic purposes. Make -Wnull-conversion use this function for better NULL macro detection. llvm-svn: 258778
* Only take NULL macros instead of all macros into account for -Wnull-conversion.Richard Trieu2016-01-091-0/+20
| | | | llvm-svn: 257240
* Exclude function calls for functions which have return type nullptr_t fromRichard Trieu2016-01-081-0/+11
| | | | | | | | | -Wnull-conversion warning. These functions are basically equivalent to other pointer returning fuctions which are already excluded by -Wnull-conversion. llvm-svn: 257231
* Only instantiate a default argument once.John McCall2016-01-061-4/+3
| | | | | | | | | | | | | | | | | | | By storing the instantiated expression back in the ParmVarDecl, we remove the last need for separately storing the sub-expression of a CXXDefaultArgExpr. This makes PCH/Modules merging quite simple: CXXDefaultArgExpr records are serialized as references to the ParmVarDecl, and we ignore redundant attempts to overwrite the instantiated expression. This has some extremely marginal impact on user-facing semantics. However, the major effect is that it avoids IRGen errors about conflicting definitions due to lambdas in the argument being instantiated multiple times while sharing the same mangling. It should also slightly improve memory usage and module file size. rdar://23810407 llvm-svn: 256983
* Improve conditional checking during template instantiation.Richard Trieu2016-01-061-24/+65
| | | | | | | | | | | | | When the condition in an if statement, while statement, or for loop is created during template instantiation, it calls MakeFullExpr with only the condition expression. However, when these conditions are created for non-templated code in the Parser, an additional SourceLocation is passed to MakeFullExpr. The impact of this was that non-dependent templated code could produce diagnostics that the same code outside templates would not. Adding the missing SourceLocation makes diagnostics consistent between templated and non-templated code. llvm-svn: 256976
* Improvements to -Wnull-conversionRichard Trieu2014-10-151-0/+20
| | | | | | | | | Split logic to separate checking function Refine the macro checking Catch nullptr->bool conversions Add some explanatory comments llvm-svn: 219774
* Don't warn on conversion from NULL to nullptr_tDavid Blaikie2013-02-161-2/+8
| | | | llvm-svn: 175331
* PR13165: False positive when initializing member data pointers with NULL.David Blaikie2012-06-211-0/+8
| | | | | | | | | This now correctly covers, I believe, all the pointer types: * 'any' pointers (both function and data normal pointers and ObjC object pointers) * member pointers (both function and data) * block pointers llvm-svn: 158931
* Enable -Wnull-conversion for non-integral target types (eg: double).David Blaikie2012-06-191-0/+1
| | | | llvm-svn: 158744
* Include the correct conversion context locations for condition expressions.David Blaikie2012-05-161-0/+8
| | | | | | | | | | | | | This improves the conversion diagnostics (by correctly pointing to the loop construct for conversions that may've been caused by the contextual conversion to bool caused by a condition expression) and also causes the NULL conversion warnings to be correctly suppressed when crossing a macro boundary in such a context. (previously, since the conversion context location was incorrect, the suppression could not be performed) Reported by Nico Weber as feedback to r156826. llvm-svn: 156901
* Don't warn when NULL is used within a macro but its conversion is outside a ↵David Blaikie2012-05-151-4/+5
| | | | | | | | | | | | | | | | | | macro. This fixes the included test case & was reported by Nico Weber. It's a little bit nasty using the difference in the conversion context, but seems to me like a not unreasonable solution. I did have to fix up the conversion context for conditional operators (it seems correct to me to include the context for which we're actually doing the comparison - across all the nested conditionals, rather than the innermost conditional which might not actually have the problematic implicit conversion at all) and template default arguments (this is a bit of a hack, since we don't have the source location of the '=' anymore, so I just used the start of the parameter - open to suggestions there) llvm-svn: 156861
* Improve some of the conversion warnings to fire on conversion to bool.David Blaikie2012-05-151-1/+10
| | | | | | | | | | | Moves the bool bail-out down a little in SemaChecking - so now -Wnull-conversion and -Wliteral-conversion can fire when the target type is bool. Also improve the wording/details in the -Wliteral-conversion warning to match the -Wconstant-conversion. llvm-svn: 156826
* Workaround a miscompile in 483.xalancbmk while we figure it out.David Blaikie2012-05-011-2/+4
| | | | llvm-svn: 155938
* PR12710 - broken default argument handling for templates.David Blaikie2012-05-011-3/+5
| | | | | | | | | | | | | | | I broke this in r155838 by not actually instantiating non-dependent default arg expressions. The motivation for that change was to avoid producing duplicate conversion warnings for such default args (we produce them once when we parse the template - there's no need to produce them at each instantiation) but without actually instantiating the default arg, things break in weird ways. Technically, I think we could still get the right diagnostic experience without the bugs if we instantiated the non-dependent args (for non-dependent params only) immediately, rather than lazily. But I'm not sure if such a refactoring/ change would be desirable so here's the conservative fix for now. llvm-svn: 155893
* Fix PR12378: provide conversion warnings on default args of function templatesDavid Blaikie2012-04-301-0/+19
| | | | | | | | | | | | | Apparently we weren't checking default arguments when they were instantiated. This adds the check, fixes the lack of instantiation caching (which seems like it was mostly implemented but just missed the last step), and avoids implementing non-dependent default args (for non-dependent parameter types) as uninstantiated default arguments (so that we don't warn once for every instantiation when it's not instantiation dependent). Reviewed by Richard Smith. llvm-svn: 155838
* Suppress macro expansion of NULL in NULL warnings.David Blaikie2012-03-161-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For "int i = NULL;" we would produce: null.cpp:5:11: warning: implicit conversion of NULL constant to integer [-Wconversion] int i = NULL; ~ ^~~~ null.cpp:1:14: note: expanded from macro 'NULL' \#define NULL __null ^~~~~~ But we really shouldn't trace that macro expansion back into the header, yet we still want macro back traces for code like this: \#define FOO NULL int i = FOO; or \#define FOO int i = NULL; FOO While providing appropriate tagging at different levels of the expansion, etc. The included test case exercises these cases & does some basic validation (to ensure we don't have macro expansion notes where we shouldn't, and do where we should) - but doesn't go as far as to validate the source location/ranges used in those notes and warnings. llvm-svn: 152940
* Provide the specific target type in the -Wnull-conversion warning.David Blaikie2012-03-151-4/+8
| | | | llvm-svn: 152835
* Reapply r152745 (reverted in 152765) now that compiler-rt is fixed.David Blaikie2012-03-151-0/+4
| | | | | | | | | | | | | | | | | Original commit message: Provide -Wnull-conversion separately from -Wconversion. Like GCC, provide a NULL conversion to non-pointer conversion as a separate flag, on by default. GCC's flag is "conversion-null" which we provide for cross compatibility, but in the interests of consistency (with -Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called -Wnull-conversion. Patch by Lubos Lunak. Review feedback by myself, Chandler Carruth, and Chad Rosier. llvm-svn: 152774
* Revert r152745 as it's breaking the internal buildbots.Chad Rosier2012-03-151-4/+0
| | | | | | | Abbreviated commit message: Provide -Wnull-conversion separately from -Wconversion. llvm-svn: 152765
* Provide -Wnull-conversion separately from -Wconversion.David Blaikie2012-03-141-0/+4
| | | | | | | | | | | | | Like GCC, provide a NULL conversion to non-pointer conversion as a separate flag, on by default. GCC's flag is "conversion-null" which we provide for cross compatibility, but in the interests of consistency (with -Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called -Wnull-conversion. Patch by Lubos Lunak. Review feedback by myself, Chandler Carruth, and Chad Rosier. llvm-svn: 152745
* Add a new warning on NULL pointer constant to integer conversion.Richard Trieu2011-05-291-0/+11
| | | | | | This path was reviewed by Chandler Carruth at http://codereview.appspot.com/4538074/ llvm-svn: 132297
* Extend the bitfield-truncation warning to initializations.John McCall2010-11-111-0/+7
| | | | | | rdar://problem/8652606 llvm-svn: 118773
* Check in this -Wconversion C++ test case that's been sitting on my machineJohn McCall2010-07-131-0/+45
for awhile. llvm-svn: 108232
OpenPOWER on IntegriCloud