[clang] [BoundsSafety][Sema] Allow counted_by and counted_by_or_null on pointers where the pointee type is incomplete but potentially completable (PR #106321)

[Dan Liew via cfe-commits]

================
@@ -19,13 +19,12 @@ struct on_member_pointer_complete_ty {
 };
 
 struct on_member_pointer_incomplete_ty {
-  struct size_unknown * buf __counted_by(count); // expected-error{{'counted_by' cannot be applied to a pointer with pointee of unknown size because 'struct size_unknown' is an incomplete type}}
+  struct size_unknown * buf __counted_by(count); // ok
----------------
delcypher wrote:

The current design is very much intentional.

Yes it's potentially problematic for API designers but most people are **not API designers**. For people who are not API designers why should consumers of that header need to care about an incomplete type if they never try to use it?

The current design also allows for something like:

```
// public_header.h

// Public and  implementation use same struct representation for `Handle`.
struct OpaqueData;
struct Handle {
  struct OpaqueData* __counted_by(count) Objects;
  size_t count;
 };

// library_internals.c

// Only the library internals knows how `OpaqueData` is defined.
struct OpaqueData {
  int real_data;
};

struct Handle alloc_handle(size_t num_objects) {
  struct Handle h;
  h.Objects = malloc(num_objects);
  h.count = num_objects

 if (!h.Objects)
  h.count = 0;

 return h;
}
```

That said we should try to help out API designers where possible. We could consider potentially emitting warnings (that have a sane suppression mechanism) for `__counted_by` pointers where the pointee never gets completed in a TU. However, if we really want that I think that belongs in a separate PR.

@rapidsna Do you have anything to add here?

https://github.com/llvm/llvm-project/pull/106321