I'm not able to reproduce the CI issue reported in rdar://143950805
locally. I don't have access to the logs from the failing bot link:
https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RD_test-simulator/5086.
So, I'm trying to re-enable this test and do some custom PR testing to
see if the bot is still failing.
rdar://143950805
This improves support for initializing instances of `std::optional` from Swift. Previously only a null optional could be initialized directly from Swift. Now instantiations of `std::optional` will get a Swift initializer that takes the wrapped value as a parameter.
rdar://118026392
Previously, we would get two copies, one accessing the pointee and one
when we pass the pointee as a method as the implicit self argument.
These copies are unsafe as they might introduce slicing. When
addressable paramaters features are enabled, we no longer make these
copies for the standard STL types. Custom smart pointers can replicate
this by making the lifetime dependency between the implicit object
parameter and the returned reference of operator* explicit via a
lifetime annotation.
rdar://154213694&128293252&112690482
Some of these tests were marked as unsupported since they were only
checking for macOS and Linux. They seem to be passing on FreeBSD as
well, so enabling them here.
This teaches ClangImporter to respect the `_Nonnull`/`_Nullable` arguments on templated function parameters.
Previously Swift would only import a non-annotated function overload. Using an overload that has either `_Nonnull` or `_Nullable` would result in a compiler error. The non-annotated overload would get imported with incorrect nullability: Swift would always assume non-null pointers, which was inconsistent with non-templated function parameters, which are mapped to implicitly unwrapped optionals.
With this change all three possible overloads are imported, and all of them get the correct nullability in Swift.
rdar://151939344
While I could not trigger a scenario where the generated macro triggers
a compilation error, the generated code is definitely not valid Swift.
rdar://151422108
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
Update availability for CxxSpan<->Span, fix lifetimebound on parameters
with reference type
Because swift-ide-test doesn't care about typechecking,
std-span-interface.swift passed despite containing 2 separate errors.
This updates the test file to properly exercise the entire compilation
pipeline for the macro expansions, by running swift-frontend
-emit-module and calling each macro expansion.
The first issue was that CxxSpan initializers taking [Mutable]Span still
had their availability set to Swift 6.2+, even after back-deploying
caused [Mutable]Span to have availability back to Swift 5.0. Since
_SwiftifyImport expansions copy the availbility of Span, this resulted
in the macro expansions calling unavailable initializers. Interestingly
enough, this manifested itself in the form of a tripped assert in SIL
verification, because although we do now typecheck the expansions from
_SwiftifyImport, the compilation can still keep going after
`shouldEmitFunctionBody` returns false: the macro expansion declaration
is still there, but is now missing its definition, despite not being
external.
The second issue was when parameters with C++ reference types were
annotated with `[[clang::lifetimebound]]`. For parameters with a type
that is `Escapable`, this is normally done using `@lifetime(borrow
foo)`. However C++ reference parameters are imported as `inout`, which
requires the `@lifetime(&foo)` syntax.
rdar://151493400
rdar://151678415
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
Both the syntax and relative order of the LLVM `nocapture` parameter
attribute changed upstream in 29441e4f5fa5f5c7709f7cf180815ba97f611297.
To reduce conflicts with rebranch, adjust FileCheck patterns to expect
both syntaxes and orders anywhere the presence of the attribute is not
critical to the test. These changes are temporary and will be cleaned
up once rebranch is merged into main.
Importing C++ class templates in symbolic mode has proven to be problematic in interaction with other compiler features, and it isn't used widely. This change removes the feature.
rdar://150528798
Add a case to LifetimeDependence.Scope to support dependencies on address-only
'let' variables. This comes up with C++ interop.
Fixes rdar://147500193 (Spurious lifetime error with closures)
When initializing span with an UnsafePointer<Element>? we call into the
generic initializer that we imported from the C++ templated constructor
instead of the concrete initializer we have in the overlay that takes an
UnsafePointer<Element> (non-optional). We cannot properly codegen for
this generic initializer at the moment, so let's stop importing them
since the user probably wanted to call the initializer from the overlay.
We should come back later and fix the root cause.
rdar://148961349
* [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
This adds conformances for C++ string types (`std::string`, `std::u16string`, `std::u32string`) to `Swift.ExpressibleByStringInterpolation`.
These conformances currently implicitly use `DefaultStringInterpolation`. In the future we can provide more performant interpolation mechanisms for C++ strings specifically that avoid the extra conversion between Swift String and C++ string types.
rdar://147249169
While we expect our users to use type aliases for template
instantiations, there are some contexts when we import instantiations
without aliases. Unfortunately, in case of C++ span we generated a name
for the instantiation that cannot be a syntactically valid Swift type
due to unary negation appearing in the type name. This PR replaces the
unary negation with "Neg" in the type name and also fixed a bug that
ended up printing certain unsigned values as signed. Moreover, this PR
also fixes some other fallouts in the SwiftifyImport macro.
rdar://146833480
These two tests require execution privileges in order to run `check-libcxx-version`, which is used to restrict the tests to a range of libc++ versions. They were failing on `non_executable` CI jobs because of missing `// REQUIRES: executable_test`.
rdar://145821727
