In derivatives of loops, no longer allocate boxes for indirect case payloads. Instead, use a custom pullback context in the runtime which contains a bump-pointer allocator.
When a function contains a differentiated loop, the closure context is a `Builtin.NativeObject`, which contains a `swift::AutoDiffLinearMapContext` and a tail-allocated top-level linear map struct (which represents the linear map struct that was previously directly partial-applied into the pullback). In branching trace enums, the payloads of previously indirect cases will be allocated by `swift::AutoDiffLinearMapContext::allocate` and stored as a `Builtin.RawPointer`.
This has the effect of rejecting unavailable overrides to available
methods in a similar way as overrides that are less available than the
introduction are rejected.
Previously, the availability was 5.3. Since
compareProtocolConformanceDescriptors was added in 5.4 and was used by
metadata accessors with baked-in checks for arguments which matched
prespecializations, 5.3 was incorrect. Moreover, now that the searching
for matches is done by getGenericMetadata, the metadata accessors no
longer contain the early exits, so running against a 5.3 runtime would
entail the metadata accessor failing to produce canonical prespecialized
records.
Here, the availability is bumped to 5.4 which includes the runtime
changes to support the metadata accessors not having early exits to
return prespecialized records.
The new function swift_getCanonicalSpecializedMetadata takes a metadata
request, a prespecialized non-canonical metadata, and a cache as its
arguments. The idea of the function is either to bless the provided
prespecialized metadata as canonical if there is not currently a
canonical metadata record for the type it describes or else to return
the actual canonical metadata.
When called, the metadata cache checks for a preexisting entry for this
metadata. If none is found, the passed-in prespecialized metadata is
added to the cache. Otherwise, the metadata record found in the cache
is returned.
rdar://problem/56995359
The new function swift_compareProtocolConformanceDescriptors calls
through to the preexisting code in MetadataCacheKey which has been
extracted out from MetadataCacheKey::compareWitnessTables into a new
public static function
MetadataCacheKey::compareProtocolConformanceDescriptors.
The new function's availability is "future" for now.
The new function `swift_compareTypeContextDescriptors` is equivalent to
a call through to swift::equalContexts. The implementation it the same
as that of swift::equalContexts with the following removals:
- Handling of context descriptors of kind other outside of
ContextDescriptorKind::Type_First...ContextDescriptorKind::Type_Last.
Because the arguments are both TypeContextDescriptors, the kinds are
known to fall within that range.
- Casting to TypeContextDescriptor. The arguments are already of that
type.
For now, the new function has "future" availability.
The previous commit broke a promise made by the implementation it replaced: if there were two or more @available(introduced:) attributes for the same platform, the greatest version wins. This commit restores that property while still completely overriding the parent platform’s availability with a child platform’s.
Previously, availability checking computed a declaration’s availability as the intersection of all @available attributes with active platforms. This meant that Swift would not allow you to use an API that was available earlier in a child platform than in its parent until it was also available in the parent platform. That was incorrect.
This PR corrects availability checking to find the most specific @available attribute with an introduced version and use that instead.
Fixes rdar://60892534.
There were a couple of methods in LangOptions and some related ones in
Availability and ASTContext that were added more recently.
Refactor the three older checks to the newer scheme.
When possible, directly reference metadata prespecializations. Doing so
is possible when the type is defined in the same module, because in
those cases the metadata accessor can be modified to ensure that the
prespecialized metadata is canonical.
rdar://problem/56994171
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
