Compatibility with earlier swift runtimes would require modifying the
runtime compatibility libraries to adjust the behavior of
checkMetadataState by way of typeForMangledNode or even
typeForMangledName. For now, simply require that a version of swift
whose runtime knows about prespecialized metadata is being targeted.
use getTypeByMangledName when abstract metadata state is requested
This can significantly reduce the code size of apps constructing deeply
nested types with conditional conformances.
Requires a new runtime.
rdar://57157619
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
UnconditionalAvailabilityKind => PlatformAgnosticAvailabilityKind
::UnavailableInCurrentSwift => ::SwiftVersionSpecific
Plus a couple related method renamings. Prep work for SR-2709.
This is the beginning of the extension of the availability model
introduced in Swift 2.0 to support two interesting things: inlineable
code and binary frameworks not tied to an OS. The former is critical
to having a stable standard library that isn't shipped with a client app.
(For more information on both of these, see docs/LibraryEvolution.rst.)
The existing availability model enforces that API is not used unless
the developer has already guaranteed its existence. We want to reuse
this logic for these new purposes. Additionally, certain queries about
the AST are dependent on this type of information as well, e.g. "can I
assume this enum will not grow any additional cases?" If the enum comes
from the module being compiled, the answer is usually "yes", but not if
the code asking the question may be inlined into another binary!
(This latter purpose is currently served by ResilienceExpansion down at
the SIL level; my goal is to replace ResilienceExpansion with
AvailabilityContext. It's a bit heavier but would also allow additional
optimization in the future.)
This commit does not change any logic; it only wraps existing uses of
VersionRange in AvailabilityContext if they're not strictly referring to
the OS version.
Following Jordan's advice, replace "join" with "union" and "meet" with
"intersect" in VersionRange to make it clear which direction these operations
go in the lattice of ranges.
Swift SVN r31640
Based on feedback from Jordan, update r30060 to synthesize availability
attributes on unannotated Obj-C protocols in the importer. This has a
user-visible effect: calls to protocol requirements with these synthesized
attributes will now cause an availability error if the requirement is not
available in the calling type refinement context.
Swift SVN r30096
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
When synthesizing a designated initializer override, we now ensure that the synthesized
initializer has the same availability as the initializer it is overriding.
Swift SVN r26732
