In some circumstances the missing trait resulted in picking the wrong
branch of some compile time conditionals resulting in code that would
not compile.
rdar://126709253
Previously the code got the declaration for types with generic
arguments and the printer used the declaration. This was a lossy
operation, we printed the type with generic parameters instead of the
arguments. This patch makes sure we print the type with the arguments.
Unfortunately, the code structure is not the most clear, type printing
is currently inherently part of the function signature printing. This
code path needs to be factored out in the future to make the code easier
to understand.
rdar://130679337
The code already forward declared strutcs and enums. This patch extends
the logic to also forward declare classes. Unfortunately, there was some
fallout because some traits ended up defined multiple times for some
classes, so the code is now extended to only conditionally emit these
traits if no forward declaration was emitted for the type yet.
rdar://124022242
The code wants to avoid exporting certain synthesized operators but it
inadvertently also prevented exporting accessors to static properties.
rdar://115564118
This PR implements proper support for optional generic associated values
in enum cases. Most of the code changes are supporting generic types in
more contexts in the printer, the rest are making sure we handle the
null pointer case when we try to get the declaration from the type that
represents a generic parameter.
rdar://131112273
Unfortunately, we cannot generate the C++ code for them just yet. There
will be a follow-up PR to actually fix the underlying issue and expose
such enums correctly.
rdar://129250756
The generated header would not compile without these dependencies. Moreover
users probably expect all-public option to be the most permissive filter
including the maximal amount of declarations.
In #74516 the `SWIFT_NOEXCEPT` specifier is added to the imported Swift
functions in C++ mode, but it is added after the function attributes. It seems
that the tests only do `-fsyntax-only`, which seems not to catch an error like
"expected function body after function declarator" when the header is
used without that flag.
Flip the attributes and the specifier around in the printer, and flip
them in all the tests.
The tests were using `%check-in-clang`, but it only checks importing as
an objective-c-header. Add a parallel `%check-in-clang-cxx` to test also
in C++. It uses C++17 because of some details in the imported headers and
disables a warning about variadic macros that was promoted to an error
and was blocking passing the tests. The clang-importer-sdk gets the
minimal set of files to compile the two modified tests as C++. The files
are mostly empty, except `cstddef` that imports the equivalent C header.
Some modifications were needed in `ctypes.h` because the header was
using features only available in C and not C++.
This feature worked prior 5.10 but the semantics was undefined. This PR
restores the behavior with the old semantics, and a separate PR will
update the documentation to describe the behavior.
Because imported enums are @objc, they were treated as unsupported in C++ and therefore ineligible to be printed in a C++ generated header. Narrow this logic so that only @objc *classes* are excluded, and update related printing logic to support enums correctly.
Fixes rdar://124262637.
Because the underlying API for fetching top-level decls returns them in an unspecified order, PrintAsClang sorts the decls before printing them to make the output order more stable. However, the rules currently implemented have at least one known defect (they compare only the unqualified name of a nested class, so two nested classes with the same Swift name sort in an arbitrary order), and there are likely many more.
Add a fallback rule which sorts declarations by their mangled name; this should at least distinguish all non-colliding ValueDecls from each other, albeit according to fairly opaque criteria. Additionally add a rule to help distinguish extensions with very similar content, and tweak other logic so that the comparison function is less likely to give up early rather than continuing to look for a usable difference.
Fixes rdar://129485103.
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.
