================
@@ -5247,6 +5247,21 @@ yet implemented in clang.
}];
}
+def MallocSpanDocs : Documentation {
+ let Category = DocCatFunction;
+ let Heading = "malloc_span";
+ let Content = [{
+The ``malloc_span`` attribute can be used to mark that a function which acts
+like a system memory allocation function and returns a span-like structure,
+where the returned memory range does not alias storage from any other object
+accessible to the caller.
+
+In this context, a span-like structure is assumed to have two fields, one of
+which is a pointer to the allocated memory and another one is an integer type
----------------
erichkeane wrote:
> With that in mind, I think we can start off strict and relax later without
> breaking code. e.g., maybe we start with supporting `int` through `long long`
> (and unsigned varieties) but not `_BitInt` initially, along with any
> non-smart pointer type. And later we relax to allow other things, and users
> can use one of the `__has_attribute` feature test macros to test for
> differences.
I hadn't thought of the start/end pointers, I think we should probably make
sure that works, that is really sensible.
As far as the integer types: `isIntegerType` includes `_BitInt` and enums,
which I think we can all admit are WRONG. So theres at least tests that need
to be written.
The more I think about it, the more I can make `int`and bigger builtin-ints
ONLY make sense. So:
```
if (const auto *BT = dyn_cast<BuiltinType>(CanonicalType))
BT->isInteger(); // plus some tests for size
```
would be reasonable.
I think the smart-pointer thing is a bridge too far, and I'm definitely OK
rejecting those, at least short term. `malloc` implies that these are pretty
darn C-esque, so smart-pointers seem like a massive extension that won't get
used.
SO I guess the fallout for me is:
pointer + integer/integer + pointer/ pointer + pointer // All need testing and
should be supported.
AND, if it is an integer, `getTypeSize(Context.IntTy) >= getTypeSize(int-type)`
would be accpetable to me.
https://github.com/llvm/llvm-project/pull/167010
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
