* [Observation] Exclude generic class types from pre-caching their keypaths
* Account for multiple nesting levels of generics for observation cached keypaths
This PR adds basic support for storing lifetime dependence information,
transform Span return types, and generate lifetime annotations.
rdar://139074571
* Import __counted_by for function return values
Instead of simply passing a parameter index to _SwiftifyInfo, the
_SwiftifyExpr enum is introduced. It currently has two cases:
- .param(index: Int), corresponding to the previous parameter index
- .return, corresponding to the function's return value.
ClangImporter is also updated to pass this new information along to
_SwiftifyImport, allowing overloads with buffer pointer return types to
be generated. The swiftified return values currently return Span when
the return value is marked as nonescaping, despite this not being sound.
This is a bug that will be fixed in the next commit, as the issue is
greater than just for return values.
* Fix Span variant selection
There was an assumption that all converted pointers were either
converted to Span-family pointers, or UnsafeBufferPointer-family
pointers. This was not consistently handled, resulting in violating the
`assert(nonescaping)` assert when the two were mixed. This patch removes
the Variant struct, and instead each swiftified pointer separately
tracks whether it should map to Span or UnsafeBufferPointer.
This also fixes return pointers being incorrectly mapped to Span when
marked as nonescaping.
A previous PR already added support to the SwiftifyImport macro to
generate safe wrappers. This PR makes ClangImporter emit the macro to do
the transformation.
This makes it possible to mark a pointer with __sized_by when the
pointee type definition is not included. The wrapper function has the
same interface as if the parameter were a void pointer, since the stdlib
has no `OpaqueBufferPointer` type.
* use swift-ide-test for checking interop signatures
* add xfail test for Span + Optional combo (Optional requires Escapable)
This is a preliminary PR to transform nonescaping std::span parameters
to Swift's Span type in safe wrappers. To hook this up with
ClangImporter, we will need generalize the noescape attribute to
non-pointer types (PR is already in review). To transform potentially
escaping spans and spans in the return position, a follow-up PR will
add lifetime annotation support. This is a building block towards
rdar://139074571.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
Previously we would not propagate those into the generated distributed
actor, making a lot of generic distributed actor protocols impossible to
express.
We indeed cannot handle protocols WITHOUT primary associated types, but
we certainly can handle them with!
This resolves rdar://139332556
Add @PointerBounds macro
@PointerBounds is a macro intended to be applied by ClangImporter when
importing functions with pointer parameters from C headers. By
leveraging C attributes we can get insight into bounds, esapability, and
(eventually) lifetimes of pointers, allowing us to map them to safe(r)
and more ergonomic types than UnsafePointer.
This initial macro implementation supports CountedBy and Sizedby, but
not yet EndedBy. It can generate function overloads with and without an
explicit count parameter, as well as with UnsafeBufferPointer or Span
(if marked nonescaping), and any of their combinations. It supports
nullable/optional pointers, and both mutable and immutable pointers.
It supports arbitrary count expressions. These are passed to the macro
as a string literal since any parameters referred to in the count
expression will not have been declared yet when parsing the macro.
It does not support indirect pointers or inout parameters. It supports
functions with return values, but returned pointers can not be bounds
checked yet.
Bounds checked pointers must be of type Unsafe[Mutable]Pointer[?]<T>
or Unsafe[Mutable]RawPointer[?]. Count expressions must conform to
the BinaryInteger protocol, and have an initializer with signature
"init(exactly: Int) -> T?" (or be of type Int).
rdar://137628612
---------
Co-authored-by: Doug Gregor <dgregor@apple.com>
When using `@DebugDescription`, only allow use of [LLDB Summary
Strings](https://lldb.llvm.org/use/variable.html#summary-strings) syntax from
`lldbDescription` properties. When `@DebugDescription` is applied to existing
`debugDescription` properties, escape any `$`, as the output of `debugDescription` is
never interpreted by LLDB.
Depends on #75305
From feedback, replace the name `_debugDescription`, which was confusing because of the
underscore, with `lldbDescription`. This new name also indicates that this property may
contain [LLDB Summary Strings](https://lldb.llvm.org/use/variable.html#summary-strings).
The macro cannot diagnose some situations, or rather, would diagnose too
aggressively, because it cannot inspect the type declarations of all
invokved types, and therefore we're unable to reliably report errors
only when necessary.
Originally I thought we don't want to emit macro code that "may fail to
compile" but we don't really have a choice.
This patch removes a manual diagnostic, and enables more correct code to
properly use @Resolvable protocols.
* `@Observable` Macro supports properties with the `package` access modifier #71060
* Cherry-pick "Move the tests for package scopes to the module interface tests" 4e274ce0a5
---------
Co-authored-by: Philippe Hausler <phausler@apple.com>
On windows (PECOFF), the `static let` properties produced by `DebugDescriptionMacro`
are not constants, and as a result the `@_section` macro cannot be applied. The error
message is:
> global variable must be a compile-time constant to use `@_section` attribute
Until this issue is addressed, DebugDescriptionMacro is disabled for windows targets.
The data emitted by `DebugDescriptionMacro` is constant. For that reason, it was placed
in `__DATA_CONST`. However, this causes a problem with the linker, which emits an error
if the `__DATA_CONST` segment is _not_ marked `SG_READ_ONLY`.
After discussion, it was pointed out that if the constant data has no fixups, then it
can and should be in the the `__TEXT` segment. The `__DATA_CONST` segment is for data
that is essentially constant but contains dyld fixups.
Fixes the way `DebugDescriptionMacro` produces a regex type name.
The problem was use of backslash escapes that weren't sufficiently escaped. They needed
to be double escaped. To avoid this trap, the regexes now use `[.]` to match a dot,
instead of the more conventional `\.` syntax.
