ddkilzer wrote: Thanks for the feedback! I will work on updates this week (around the WebKit Contributors meeting, which happens to be the same week as the LLVM Developer's Meeting).
In the meantime, the checker (using the original PR) has already found some `std::span` anti-patterns in WebKit that were easy to fix: - https://github.com/WebKit/WebKit/pull/35562 - https://github.com/WebKit/WebKit/pull/35581 - https://github.com/WebKit/WebKit/pull/35585 — Also, in addition to creating a `std::span` from function parameters (mentioned in [this feedback](https://github.com/llvm/llvm-project/pull/112784#discussion_r1807926397)), this checker found another pattern that we may want the checker to recognize, which is a function that returns a pointer and takes a reference (or a pointer) to a length variable (example take from [this code](https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/runtime/IntlObject.cpp#L1634) in WebKit): ``` UErrorCode status = U_ZERO_ERROR; [...] int32_t length = 0; const char* pointer = uenum_next(enumeration.get(), &length, &status); String calendar(std::span { pointer, static_cast<size_t>(length) }); ``` Where the `uenum_next()` function is defined as: ``` const char* uenum_next(UEnumeration* en, int32_t* resultLength, UErrorCode* status); ``` One could also imagine a function that returns a length and passes in a pointer or a reference to a buffer. However, we want to be careful about accepting this pattern if the function is in the current project, which assumes it could be improved, like this example for `PAL::TextCodec::getUnencodableReplacement()`: - https://github.com/WebKit/WebKit/pull/35562 https://github.com/llvm/llvm-project/pull/112784 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
