================
@@ -373,6 +373,13 @@ void ReadFunctionInfo(const uint8_t *&Data, FunctionInfo
&Info) {
endian::readNext<uint16_t, llvm::endianness::little>(Data);
Info.ResultType = std::string(Data, Data + ResultTypeLen);
Data += ResultTypeLen;
+
+ unsigned SwiftReturnOwnershipLength =
+ endian::readNext<uint16_t, llvm::endianness::little>(Data);
+ Info.SwiftReturnOwnership = std::string(reinterpret_cast<const char *>(Data),
+ reinterpret_cast<const char *>(Data)
+
+ SwiftReturnOwnershipLength);
----------------
fahadnayyar wrote:
@compnerd my approach approach for `SwiftReturnOwnership` was to do something
similar to `ResultType`. Another reason for choosing `std:string` instead of
`enum` was that `SwiftImportAs` is also implemented as `std:string`.
`SWIFT_RETURNS_(UN)_RETAINED` annotation is closely related to
`SWIFT_SHARED_REFERENCE` annotation. So I wanted to keep APINotes
implementation of both of these similar.
But I do agree that `enum` is a better approach for compression and
diagnostics. But I also feel we'd not se much benefit unless we change other
things like `SwiftImportAs` also to use `enums` for implementation. Do you
think we should do such refactoring for all the annotations together in a
separate follow-up patch?
https://github.com/llvm/llvm-project/pull/118938
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
