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.
Generated interfaces for Clang modules used to try printing normal
comments between decls extracted from the header text. That was because
doc-comment was not common in C/ObjC headers. But mainly because of
"import as member feature" Clang decls aren't printed in the order as
they appear in the header file, the logic determinig which comment
belongs to which decl was not working property. We've decided to remove
that feature and only print the proper doc-comments as it has been
getting common.
rdar://93731287
When importing a C++ class template instantiation, Swift translates the template parameter type names from C++ into their Swift equivalent.
For instance, `basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t>>` gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `wchar_t` is imported as `CWideChar`, which is a typealias for `Scalar` on most platforms including Darwin. Notice that Swift goes through the `CWideChar` typealias on the specific platform. Another instantiation `basic_string<uint32_t, char_traits<uint32_t>, allocator<uint32_t>>` also gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `uint32_t` is also imported as `Scalar`. This is problematic because we have two distinct C++ types that have the same name in Swift.
This change makes sure Swift doesn't go through typealiases when emitting names of template parameters, so `wchar_t` would now get printed as `CWideChar`, `int` would get printed as `CInt`, etc.
This also encourages clients to use the correct type (`CInt`, `CWideChar`, etc) instead of relying on platform-specific typealiases.
rdar://115673622
Record up to two errors emitted when we fail to
load a module for interface generation, and include
these errors in the message we pass back to the
editor. This should help us better pin down the
reason why interface generation failed.
rdar://109511099
This ensures that interface gen reports an error when importing a framework Swift module
that also imports the underlying C++ module into Swift, when interop is disabled, so that
we can retry the interface gen with interop enabled.
Rather than using `ModuleDecl::isSystemModule()` to determine whether a
module is not a user module, instead check whether the module was
defined adjacent to the compiler or if it's part of the SDK.
If no SDK path was given, then `isSystemModule` is still used as a
fallback.
Resolves rdar://89253201.
`@Sendable` on completion handlers imported from Objective-C has been
implemented for a while, but has been disabled in production builds
due to a number of problems we've encountered with rolling it out.
Introduce an experimental feature for `@Sendable` completion handlers
so we can iterate on this more before we enable it by default.
Part of rdar://85569247, which will cover re-landing this feature.
* InterfaceGen reports a primary associated type as a reference to the
'associatedtype' declaration
* CursorInfo on a primary associated type returns information of the
'associatedtype' declaration
rdar://93275458
Custom attributes were not printed because they are marked
'UserInaccesible'.
* Make CustomAttr 'RejectByParser' instead of 'UserInaccessible'
* Remove special treatment for Result Builder attributes
* Load implicit modules in module/header interface gen requests
rdar://79927502
If a method has an `async` variant, the non-`async` variant will now mark its completion handler parameter `@Sendable`. This shouldn't be a breaking change in Swift 5 code since these declarations are automatically `@_predatesConcurrency`.
Also adds:
• Support for `@_nonSendable` on parameters, which can be used to override this implicit `@Sendable`
• Support for `@Sendable` on block typedefs; it's generally going to be a good idea to mark completion block typedefs `@Sendable`.
Fixes rdar://85569247.
Ultimately this is to support the disambiguation of protocol requirements when printing stubs. This allows us to disambiguate the case where two modules declare a nominal type, and when that type appears in a protocol requirement. In such a case, we now fully qualify the types involved.
Fixing this also appears to now be consistently printing module qualification in many more places, hence the updates to the IDE/SourceKit tests.
rdar://72830118
Arguments in `SubscriptExpr` are visited since the recent `ArgumentList`
refactoring, but were being added to the containing `CallExpr`. Add a
node for the `SubscriptExpr` itself so that its argument is added there
instead of the `CallExpr`.
Also remove `key.nameoffset` and `key.namelength` from the response when
both are 0 to match the rest of the offsets and lengths.
Resolves rdar://85412164.
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.
Instead of a new attribute `@completionHandlerAsync`, allow the use of
the existing `renamed` parameter of `@available` to specify the
asynchronous alternative of a synchronous function.
No errors will be output from invalid names as `@completionHandlerAsync`
had, but if a function is correctly matched then it will be used to
output warnings when using the synchronous function in an asynchronous
context (as before).
Resolves rdar://80612731
Mark imported `@completionHandlerAsync` attrs as
implicit, which avoids printing them in generated
interfaces. And for the sake of completion,
serialize the implicit bit in case it's used
elsewhere in the future.
To make sure we continue to print
`@completionHandlerAsync` attributes explicitly
written by the user in Swift, add a SourceKit
interface test.
Resolves rdar://76685011
Generated Swift interfaces for modules with overlays, like Foundation or Dispatch, currently contain `import Foundation`/`import Dispatch` statements.
These imports are redundant, and this change removes them.
This affects module interfaces, interface generation in sourcekitd, and
diagnostics. Also fixes a fixit that was assuming the 'OSX' spelling when
computing the source range to replace.
Resolves rdar://problem/64667960
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
This attribute is intended to mean there's a replacement declaration that
should be used instead in Swift code. We already filter out decls with this
attribute in code completion, but were still exposing them in generated
interfaces.
Resolves rdar://problem/62464954
While the decls being printed for header file generated interfaces were mapped
from the top-level clang decls in that file, the Swift decls they correspond to
may not be top-level. E.g. top-level functions in the header file can be mapped
to property accessors on the Swift side, which were being printed simply as
"get" at the top level.
This updates header interface generation to map each decl to its top-level decl
before printing.
Resolves rdar://problem/63409659
Out handling of clang submodules was handled differently between DocInfo and
InterfaceGen. For InterfaceGen submodules were mapped back to their top-level
clang modules (or their Swift overlay if it had one) before being passed
into printSubmoduleInterface, along with the dot separated name of the submodule.
For DocInfo, they were not, and only the rightmost component of their name was
passed. The call to retrieve the decls from a ModuleDecl doesn't work if the
ModuleDecl wraps a clang submodule, so we were missing these decls.
InterfaceGen for submodules also shouldn't have been mapping the module back to
the overlay of top-level clang module, as that meant we ended up printing
import decls from the Swift overlay in the submodule's interface.
Resolves rdar://problem/57338105
We weren't handling this case, so their generated interfaces / doc info
wouldn't include symbols from the cross-import overlays, and we wouldn't
map the underscored cross-import overlay name back to the declaring
framework's name in cusor-info, completion results or when indexing.
Resolves rdar://problem/62138551
