Any safe wrapper expansion originating in a bridging header would fail
typechecking because the `__ObjC` module doesn't import the standard
implicit imports. This is because the main module is not available to
inherit implicit imports from when the `__ObjC` module is created. We
don't need all of the implicit modules for safe wrappers, so import
`Swift` specifically.
rdar://163078116
Inheriting a clang import marked `requires: !swift` will always result
in an error. This skips such imports, which *may* result in name lookup
errors instead, but also may not, depending on the module.
rdar://161795145
Since the compiler invokation performing the macro expansion dump
redirects its stderr output, any errors are not displayed by default.
This is extra problematic for test failures in CI. By performing the
compiler invokation with -verify first, errors are shown.
Importing clang submodules results in an implicit import of the
top-level module as well. This can result in the same TLM being imported
many different times, if multiple submodules are imported from the same
module. This deduplicates these imports.
Other imports are not expected to be duplicated, so care is taken to
only deduplicate clang TLM imports.
Non-explicit submodules don't need to be explicitly added to the list of
imports to be visible, since their decls are implicitly exported. Skip
these modules even when present in the list of imports. Explicit
submodules are imported *regardless* of whether another module
imports them however.
The imported top-level module inherits the imports of all its
(transitive) submodules. Since multiple submodules can import the same
modules these need to be deduplicated to avoid redundant work.
This flag dumps all imports for each SourceFile after it's gone through
import resolution. It is only intended for testing purposes.
There are other ways to print imports, but they don't correspond 1:1 to
the imports actually resolved, which is a bit problematic when testing
implicit clang module imports.
Decls in Swift wrapper module may not originate in the top-level clang
module with the same name, since decls in clang submodules are dumped
into the top-level module. This is because Swift has no concept of
submodules. To make sure that any imported decl has access to the same
symbols as the original clang decl had, all transitive submodules, and
their imports, are added as implicit imports of the wrapper module. This
is necessary in the case where a submodule is marked `explicit`.
The content in explicit submodules isn't normally made visible when
importing the parent module. Decls from explicit submodules still
end up in the top-level wrapper module however, so in Swift they do
still need to be visible from the top-level module. This is relevant
for macro expansions, so that they can refer to the same types as the
original decl.
When macros like _SwiftifyImport are added to a wrapper module for a
clang module, they may need to refer to symbols declared in another
clang module that the wrapped module imports (e.g. because they are used
in the original signature). This adds all the imported clang modules as
implicit imports to the wrapper module.
rdar://151611573
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
The `stable/20250601` Clang apparently wants an attributed parameter to
have a name, and that the attributes follow the name:
```
/Users/alatsis/Desktop/rebranch/swift/test/Interop/C/swiftify-import/Inputs/counted-by-lifetimebound.h:7:76: error: 'lifetimebound' attribute only applies to parameters and implicit object parameters
int * __counted_by(len) simple(int len, int len2, int * __counted_by(len2) __lifetimebound p);
^
/Users/alatsis/Desktop/rebranch/swift/test/Interop/C/swiftify-import/Inputs/counted-by-lifetimebound.h:5:40: note: expanded from macro '__lifetimebound'
^
```
Also humor the compiler here:
```
3 | #define __counted_by(x) __attribute__((__counted_by__(x)))
| `- note: expanded from macro '__counted_by'
4 | #define __counted_by_or_null(x) __attribute__((__counted_by_or_null__(x)))
5 | #define __lifetimebound __attribute__((lifetimebound))
:
22 | int * __counted_by(len) noncountedLifetime(int len, int * p __lifetimebound);
23 |
24 | int * __counted_by(13) _Nullable constant(int * _Nullable p __counted_by(13) __lifetimebound);
| `- error: combining '__counted_by' with non-zero count (which cannot be null) and '_Nullable'; did you mean '__counted_by_or_null' instead?
```
Integer literal expressions with types that are not of type `int` are
printed with a suffix to indicate the type (e.g. `123U` or `456L` for
`unsigned` and `long`). This is not valid syntax for integer literals in
Swift, so until we fully translate the count expr syntax to Swift we
need to avoid importing these count expressions.
Also fixes some -Werror related stuff in test cases.
rdar://154141719
This enables -strict-memory-safety -warnings-as-errors on the Swift side
to verify that the macro expansions don't cause any warnings and that
they use `unsafe` correctly. On the clang side it enables -Xcc -Werror.
To reduce noise in the test output and pass -Werror cleanly it also
enables -Xcc -Wno-nullability-completeness. This will make it easier to
detect mistakes when writing tests, because warnings stand out whereas
previously they've been drowned out in the noise.
Previously we would emit a macro that would error on expansion when
trying to add a safe wrapper to a function with __sized_by on a type
that mapped to UnsafePointer<T> instead of UnsafeRawPointer or
OpaquePointer. __sized_by is acceptable when used on byte-sized pointee
types, so this adds machinery in the macro expansion to support that.
Meanwhile on the ClangImporter side, we add a check so that __sized_by
on pointee types with a size is ignored if that size is larger than 1
byte.
When _SwiftifyImport applies .sizedBy to a pointer of type
UnsafePointer<T> it will still map it to a
RawSpan/UnsafeRawBufferPointer in the safe overload. The assumption is
that any API using __sized_by is dealing with raw bytes, so raw pointers
are a better Swift abstraction than UnsafePointer<CChar> etc. It also
lets the user avoid doing a scary pointer cast from some potentially
larger-than-byte-sized pointer to a byte-sized pointer. Casts to
RawPointers are generally safer and more ergonomic.
rdar://150966684
rdar://150966021
Previously we did not remove count parameters if any count parameters
were shared between count expressions, or if any count expression
contained operations. Buffer sizes were also just checked to be larger
than or equal than the given count.
We now extract the count from Spans/BufferPointers whenever possible,
and store that value in a variable at the start of the function. If
multiple parameters share the same count, a bounds check is emitted to
make sure that they have the same size. Subspans can be used if one span
is larger than necessary.
The message in the bounds check is changed so that it includes the
expected and actual value, to aid in debugging.
This patch also fixes some incorrect indentation, and adds the
Whitespace.swift test case to act as a regression test in case the
indentation changes, since the other test cases don't use significant
whitespace.
rdar://151488820
rdar://151511090
rdar://146333006
rdar://147715799
Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.
To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.
rdar://151206394
Parameters can be named with keywords without escaping, because it's
unambiguous in the grammar that they are parameters. They still need to
escaped when referred to inside the function body however. This escapes
all references to parameters using backticks.
Parameter names are also checked for clashes with the function name - in
such cases the parameter is renamed in the same way as unnamed
parameters.
rdar://151024645
Nullable return Spans did not include __swiftifyOverrideLifetime,
resulting in a lifetime error when returning the Span. Meanwhile return
values for __sized_by did not use the correct label for the call to the
RawSpan initializer, using `count` instead of `byteCount`.
rdar://151804085
rdar://151799287
Swift nodes imported from clang don't have doc comments carried over,
but IDEs are clever enough to fetch the comments from the associated
clang node. The swift node in the macro expansion from _SwiftifyImport
doesn't have a clang node directly associated with it however.
This patch adds the same comment from the clang node to the
_SwiftifyImport macro invocation node. Since the macro has access to
this node, it can easily copy over its leading trivia.
For now the comment is not altered at all, meaning @param still remains
even if the parmeter is removed.
rdar://151346977
_SwiftifyImport doesn't know how to handle
AutoreleasingUnsafeMutablePointer, so we should not attach any
.countedBy information for pointers that are imported as this type.
This also adds defensive checks against adding .countedBy to any pointer
type that _SwiftifyImport doesn't know how to transform.
rdar://151479521
_SwiftifyImport would expand with syntax errors if applied to a function
with anonymous parameters, because it would try to refer to parameters
using the name `_`. Detect these cases and create names for unnamed
parameters.
rdar://150955944
__counted_by (and __sized_by) expressions can have arbitrary C syntax
in them, such as:
void foo(int * __counted_by(*len) p, int *len);
When @_SwififyImport tries to generate Swift code for this, the
expression `*len` leads to a syntax error, since it isn't valid Swift.
This patch adds a check to ensure we only attach the Swiftify macro to
__counted_by expressions that are also syntactically valid in Swift.
rdar://150956352
* [Swiftify] Emit Mutable[Raw]Span when possible
Previously wrappers would use UnsafeMutable[Raw]Pointer for mutable
pointers, and Span for non-const std::span, to prevent the compiler from
complaining that MutableSpan didn't exist.
Now that MutableSpan has landed we can finally emit MutableSpan without
causing compilation errors. While we had (disabled) support for MutableSpan
syntax already, some unexpected semantic errors required additional
changes:
- Mutable[Raw]Span parameters need to be inout (for mutation)
- inout ~Escapable paramters need explicit lifetime annotations
- MutableSpan cannot be directly bitcast to std::span, because it is
~Copyable, so they need unwrapping to UnsafeMutableBufferPointer
rdar://147883022
* [Swiftify] Wrap if-expressions in Immediately Called Closures
When parameters in swiftified wrapper functions are nullable, we use
separate branches for the nil and nonnil cases, because
`withUnsafeBufferPointer` (and similar) cannot be called on nil.
If-expressions have some limitations on where they are allowed in the
grammar, and cannot be passed as arguments to a function. As such, when
the return value is also swiftified, we get an error when trying to
pass the if-expression to the UnsafeBufferPointer/Span constructor.
While it isn't pretty, the best way forward seems to be by wrapping the
if-expressions in Immediately Called Closures.
The closures have the side-effect of acting as a barrier for 'unsafe':
unsafe keywords outside the closure do not "reach" unsafe expressions
inside the closure. We therefore have to emit "unsafe" where unsafe
expressions are used, rather than just when returning.
rdar://148153063
__counted_by already had MutableSpan support, so add it for std::span
for parity. But since MutableSpan hasn't landed in the standard library
yet, disable emitting it to prevent compilation errors in expansions.
rdar://147882736
__counted_by return values with .lifetimeDependence are now mapped to
Span instead of UnsafeBufferPointer. Also fixes bug where std::span
return values would map to Span even if lifetime dependence info was
missing.
