Commit Graph

14 Commits

Author SHA1 Message Date
Richard Smith 5e9746f520 DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.

This is a re-commit of r284800.

llvm-svn: 284890
2016-10-21 22:00:42 +00:00
Renato Golin 41189656ed Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules."
This reverts commit r284800, as it failed all ARM/AArch64 bots.

llvm-svn: 284811
2016-10-21 08:03:49 +00:00
Richard Smith 0c1c53e3fa DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.

llvm-svn: 284800
2016-10-21 02:36:37 +00:00
Richard Trieu 3bb8b56a5d PR16074, implement warnings to catch pointer to boolean true and pointer to
null comparison when the pointer is known to be non-null.

This catches the array to pointer decay, function to pointer decay and
address of variables.  This does not catch address of function since this
has been previously used to silence a warning.

Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.

void foo() {
  int arr[5];
  int x;
  // warn on these conditionals
  if (foo);
  if (arr);
  if (&x);
  if (foo == null);
  if (arr == null);
  if (&x == null);

  if (&foo);  // no warning
}

llvm-svn: 202216
2014-02-26 02:36:06 +00:00
David Blaikie a1edff0046 PR14284: crash on ext-valid returning NULL from a void function
llvm-svn: 167565
2012-11-08 00:41:20 +00:00
Nico Weber ccec40d9b7 Add -Wstring-plus-int, which warns on "str" + int and int + "str".
It doesn't warn if the integer is known at compile time and within
the bounds of the string.

Discussion: http://comments.gmane.org/gmane.comp.compilers.clang.scm/47203
llvm-svn: 151943
2012-03-02 22:01:22 +00:00
Richard Trieu aee9e76722 The current warning in -Wnull-arithmetic for comparisons between NULL and non-pointers is not very helpful. This patch will update the wording to be more helpful to users.
Old warning:

warning: use of NULL in arithmetic operation [-Wnull-arithmetic]
  return 10 <= NULL;
            ^  ~~~~

New warning:

warning: comparison between NULL and non-pointer ('int' and NULL) [-Wnull-arithmetic]
  return 10 <= NULL;
         ~~ ^  ~~~~
llvm-svn: 137377
2011-08-11 22:38:21 +00:00
Chandler Carruth c933221826 Factor out (some of) the checking for invalid forms of pointer
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.

The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.

Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.

llvm-svn: 133906
2011-06-27 08:02:19 +00:00
Chandler Carruth 44d5c1e063 Use an explicitly 64-bit triple flag to ensure we can easily verify the
types printed in various diagnostics.

We could omit checking for the types, but that can mask errors where the
wrong type is streamed into the diagnostic. There was at least one of
these caught by this test already.

llvm-svn: 133429
2011-06-20 08:59:25 +00:00
Chandler Carruth 5f380da06f Fix a problem with the diagnostics of invalid arithmetic with function
pointers I found while working on the NULL arithmetic warning. We here
always assuming the LHS was the pointer, instead of using the selected
pointer expression.

llvm-svn: 133428
2011-06-20 07:52:11 +00:00
Chandler Carruth 4f04b436f8 Move away from the poor "abstraction" I added to Type. John argued
effectively that this abstraction simply doesn't exist. That is
highlighted by the fact that by using it we were papering over a more
serious error in this warning: the fact that we warned for *invalid*
constructs involving member pointers and block pointers.

I've fixed the obvious issues with the warning here, but this is
confirming an original suspicion that this warning's implementation is
flawed. I'm looking into how we can implement this more reasonably. WIP
on that front.

llvm-svn: 133425
2011-06-20 07:38:51 +00:00
Chandler Carruth e1db1cf0c3 Add test cases for false positives on -Wnull-arithmetic from Richard
Trieu, and fix them by checking for array and function types as well as
pointer types.

I've added a predicate method on Type to bundle together the logic we're
using here: isPointerLikeType(). I'd welcome better names for this
predicate, this is the best I came up with. It's implemented as a switch
to be a touch lighter weight than all the chained isa<...> casts that
would result otherwise.

llvm-svn: 133383
2011-06-19 09:05:14 +00:00
Richard Trieu fc51bc1cea Put the new warning from revision 133196 on NULL arithmetic behind the flag -Wnull-arthimetic and set to DefaultIgnore. A few edge cases need to be worked out before this can be set to default.
llvm-svn: 133287
2011-06-17 20:35:48 +00:00
Richard Trieu 701fb36b95 Add a new warning when a NULL constant is used in arithmetic operations. The warning will fire on cases such as:
int x = 1 + NULL;

llvm-svn: 133196
2011-06-16 21:36:56 +00:00