When printing the public `.swiftinterface` for a `-library-level=api` module,
skip emitting `@available`, `@backDeployed`, and `@_originallyDefinedIn`
attributes that reference "SPI" platforms.
Resolves rdar://133990140.
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 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.
Recently, unexpected binary module sharing between compilers that had
inconsistent views of the `PlatformKind` enumeration caused me to spend several
days debugging undefined behavior in the compiler. We should validate that
enumeration values decoded during deserialization are valid, and fail fast when
they are not to make debugging this kind of issue less time consuming. This
change just validates the `PlatformKind` value decoded for an `AvailableAttr`,
but more of deserialization could be updated to do similar validation.
Resolves rdar://123770273
Unavailable decl optimization is meant to optimize declarations that are
unreachable at runtime. A declaration that is marked unavailable in app
extensions (e.g. `@available(macOSApplicationExtension, unavailable)`) may be
reachable by non-extension processes so it cannot be safely optimized.
Resolves rdar://122924862
The isPlatformActive() function wants to choose between Target and TargetVariant.
It currently copies in to a local to do this, but Triple contains strings which result
in allocations for the copy.
This uses a pointer instead, to avoid the allocations entirely, reducing total allocations
in the compiler by 5%.
rdar://117879768
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
In #31686 changes were introduced to ensure that capacity was stored in
the ManagedBuffer allocation, and @lorentey sugested that as a stopgap
measure for addressing the lack of platform malloc introspection on
OpenBSD, we use Swift availability attributes instead on the relevant
parts of ManagedBuffer and friends.
Since platform availability symbols must be specifically set up to be
used, this commit does so in advance of the above change.
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
Add a platform kind and availability attributes for macCatalyst. macCatalyst
uses iOS version numbers and inherits availability from iOS attributes unless
a macCatalyst attribute is explicitly provided.
For the moment, we do not consider APIs deprecated earlier than watchOS 2.0 as
unavailable. rdar://problem/20948019 track changing this once the ultimate
decision on this policy has been made.
This addresses the compile-time components of rdar://problem/20774229
Swift SVN r28559
Change the active-platform availability logic to not consider iOS as active on
tvOS. We want all of the messiness of the fact that tvOS was branched
from iOS to be handled in clang, which "transcribes" iOS availability attributes
to their corresponding tvOS counterparts as long as there is not an
existing explicit tvOS availability attribute on the declaration.
This change exposed several places where I needed to add explicit handling of
of tvOS and where we will need to handle watchOS as well.
rdar://problem/20774229 tracks adding logic and tests to handle watchOS in these
places.
It is also unfortunately the case that llvm::triple returns true when isiOS()
is called on tvOS. This means that to test whether an llvm:triple target is
really iOS, we need to check for iOS then check explicitly that it is not
tvOS. We will eventually change llvm's behavior here so that the double
check is not needed.
Swift SVN r28013
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
This patch adds the beginning of building the type refinement context tree for
availability checking in Sema, guarded by by the
-enable-experimental-availability-checking option. This tree parallels the AST
but is much more sparse: we introduce a new TypeRefinementContext only when
needed. Each context refines the range of potential OS versions that could be
encountered at run time. For the moment, we only refine contexts for function
bodies. I will add refinement contexts for #os(...) in a later commit.
The AST is not directly connected to the TRC tree except at the SourceFile
level; when type checking, we use source locations to look up the TRC
corresponding to an AST element. For the moment, we emit a diagnostic when the
programmer references a potentially unavailable declaration. We will later
change this to treat the declaration as if it had optional type.
Swift SVN r22145
