Create two versions of the following functions:
isConsumedParameter
isGuaranteedParameter
SILParameterInfo::isConsumed
SILParameterInfo::isGuaranteed
SILArgumentConvention::isOwnedConvention
SILArgumentConvention::isGuaranteedConvention
These changes will be needed when we add a new convention for
non-trivial C++ types as the functions will return different answers
depending on whether they are called for the caller or the callee. This
commit doesn't change any functionality.
We export cdecl function declarations twice: for Objective-C and for
C++. When the code is compiled in Objective-C++ both of the declarations
are visible to the compiler. The generated header did not compile,
because only one of the declarations were noexcept. There are multiple
possible ways to fix this issue, one of them would make only C++
declarations visible in Objective-C++ mode. However, for this particular
problem I decided to also make the Objective-C functions SWIFT_NOEXCEPT.
This approach resolves the inconsistency that broke the code when
compiled in Objective-C++ mode. Moreover, Swift guarantees that those
cdecl declarations cannot raise errors, so in case we only generate the
C declarations and consume them from C++ or Objective-C++, those are the
correct declarations.
rdar://129550313
The generated thunks for functions can refer to some internal methods of
their arguments. As a result, those generated thunks should always be
after the definitions of the corresponding argument types. The printer
ordered the declarations by name, and Swift had the convention starting
types with upper case letters and functions with lower case letters.
This naming convention together with the ordering resulted in the
correct ordering in most of the cases. There were a couple of exceptions
when people diverged from the naming conventions or wanted to export
operators. This patch fixes this problem by always ordering type decls
before function decls.
rdar://129276354
The clang nodes associated with Swift's Core Foundation types can already be
represented by a pointer. The interop code does not need to add an extra
layer of indirection in those cases.
rdar://119840281
The function responsible for printing signatures can return in the middle
of the printing process whenever it discovers an unsupported scenario.
To avoid creating a header that cannot be compiler, this function should
be transactional. It either has to succeed and write the signature to the
stream, or in case it failed, the stream should be untouched. This patch
introduces a temporary buffer that is flushed to the stream as the last
step for a successful execution. This should make the user experience
better whenever the user stumbles upon something that is unsupported.
In some cases, the reverse interop generated both a forward declaration and a
definition with unavailable attribute in the C++ header. Unfortunately, the
kinds of these symbol did not match. The forward declaration was templated
while the definition was not. The forward declaration has the correct kind,
so this patch extends the printing of unavailable definitions to include the
generic arguments.
rdar://119835933
In Swift, we can have enum elements and methods with the same name, they are overloaded.
Unfortunately, this feature is not supported by C++ interop at the moment. This patch
avoids emitting the methods with name collisions to make sure the resulting header
can be compiler. A proper fix should follow in a later PR.
rdar://128162252
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This now specifies a category name that’s used in TBDGen, IRGen, and PrintAsClang. There are also now category name conflict diagnostics; these subsume some @implementation diagnostics.
(It turns out there was already a check for @objc(CustomName) to make sure it wasn’t a selector!)
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Extend the previous commit’s support for functions that return Never to also properly generate code for *throwing* Never functions. This is a little subtle because:
• At the SWIFT_CALL level, throwing Never functions are *not* noreturn
• At the thunk level, throwing Never functions are noreturn *only* if you’re using exceptions; if you’re using swift::Expected, they should throw
• In either case, the compiler cannot statically prove that thunks are noreturn except on the error path, so we need to add an abort() call on the success path
Swift-to-C++ thunk printing for functions didn’t really take into account Swift’s `Never` type. This type maps to `SWIFT_NORETURN`, but it also requires other tweaks to code generation, such as omitting the `return` keyword. (Removing that requires minor changes to many tests.)
Fixes rdar://124137073.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
When printing an ObjC member into a header with an `Int` parameter or result, PrintAsClang would look up any imported Objective-C member it overrode to see if ClangImporter imported `NSUInteger` as `Int`, and if so, would print `NSUInteger` instead of `NSInteger`. However, it did not do the same for protocol requirements the member witnessed. Correct this oversight.
Fixes rdar://124300674.
As we do with Swift structs, emit the members of extensions of Swift
enums into the corresponding C++ class. This includes exposing more of
the Optional API from the standard library into Swift.
Noncopyable and nonescaping APIs in Swift can be expressed in C++ with
some downsides. Teach the AST printer to be more lenient, allowing
Swift APIs involving noncopyable and nonescapable types to be printed.
Previously we only excluded implicitly-created overrides, but it turns out explicit overrides are just as problematic and just as unnecessary.
Fixes rdar://123633538.
The checking should be as simple as checking for `isAny()` or `isAnyObject()`
on an existential type because all of the non-inverse protocol requirements
are going to form a protocol composition type.
[interop][SwiftToCxx] Ignore delayedMembers in C++
This fixes a bug where an ObjC @interface declaration is emitted for a
class that has a member that isn't emitted.
Resolves rdar://119835836
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
This is needed as the metadata for C++ types might not be actually emitted and thus we can't always reference it
Fixes https://github.com/apple/swift/issues/69234
rdar://117089662
