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
(cherry picked from commit 374658a)
Previously we would not import decls containing these types. This was
not an issue, because they can only occur when -fbounds-safety or
-fexperimental-bounds-safety-attributes is passed to clang. When
SafeInteropWrappers is enabled we pass
-fexperimental-bound-safety-attributes to clang however, so these types
can now occur without the user specifying any -Xcc flags.
rdar://151611718
(cherry picked from commit ac068c2a6b)
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
(cherry picked from commit f5fa481205)
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
(cherry picked from commit 0f312adb92)
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
(cherry picked from commit ebe2c60f43)
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
(cherry picked from commit 6534b9b14f)
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
(cherry picked from commit 526c683)
_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
(cherry picked from commit 8e27947b2a)
__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
(cherry picked from commit e5b1f4a251)
[Swiftify] Don't use count from Span inside withUnsafeBufferPointer c… (#81316)
Given a call like: ptr.withUnsafeBufferPointer { _ptrPtr in ... } ptr.count and _ptrPtr.count both contain the same value, but when ptr is a MutableSpan we get an error when referring to ptr inside a call to withUnsafeMutableBufferPointer, so we should use _ptrPtr.count instead.
rdar://150551109
[Swiftify] add _swiftifyOverrideLifetime for return Spans
std::span imports already have _cxxOverrideLifetime for their return
values. __counted_by needs the same, but Cxx may not be available at the
macro site, so we introduce _swiftifyOverrideLifetime in SwiftifyImport.
rdar://150569220
* [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.
Usage of Span was temporarily behind an experimental feature flag. Now
that SE-0447 has been accepted, remove the experimental feature flag and
allow Span usage everywhere.
Implements rdar://144819992.
PredictableMemoryAccessOptimizations has become unmaintainable as-is.
RedundantLoadElimination does (almost) the same thing as PredictableMemoryAccessOptimizations.
It's not as powerful but good enough because PredictableMemoryAccessOptimizations is actually only needed for promoting integer values for mandatory constant propagation.
And most importantly: RedundantLoadElimination does not insert additional copies which was a big problem in PredictableMemoryAccessOptimizations.
Fixes rdar://142814676
When we generate a safe wrapper that only differs in the return type we
might introduce ambiguities as some callers might not have enough
information to disambiguate between the overloads. This PR makes sure
the newly generated declarations are marked as @_disfavoredOverload so
the compiler can keep calling the old functions without a source break
when the feature is turned on.
rdar://139074571
This passes along the noescape attribute to @_SwiftifyImport as
.noescape(pointer: .param(X)). This allows importing parameters as Span,
MutableSpan and RawSpan.
* 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.
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)
* 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
This results in an automatic wrapper function with safe pointer types
when the imported function has bounds attributes. This exercises similar
pathways as the recently added functionality for specifying macros from
swift_attr. The new functionality is guarded by the experimental
language feature SafeInteropWrappers.
rdar://97942270
This test has been disabled since 2022.
This re-enables the test in order to have some test coverage of the `-experimental-c-foreign-reference-types` compiler flag.
See `test/Interop/Cxx/foreign-reference/reference-counted.swift` for a very similar test that enables C++ interop.
rdar://101790203
Due to a now default-enabled `undef` pass (llvm/llvm-project
1b1c8d83d3567a60280291c0adb95d1d60335509), a whole bunch of interop
IRGen tests are failing due to missing `undefs`, even though they don't
matter in these tests at all. Add regex matches so that these tests just
check for the name and types of the functions they care about.
If possible, add imported members to the StructDecl's LookupTable rather than adding them directly as members. This will fix the issues with ordering that #39436 poorly attempted to solve during IRGen.
This also allows us to break out most of the test changes from #39436.
Add an convert to the new `target-swiftxx-frontend` substitution in lit
to control the C++ interop enabling in Swift. This allows for a single
site which will enable control of both an overridden standard (for
testing multiple C++ standards) and simplify writing tests.
