Representing introduced, deprecated, and obsoleted versions at rest as optional
version tuples is redundant, since the empty version tuple already represents
"version not present".
NFC.
This request will finish type checking an AvailableAttr by resolving its domain
and then enforcing any restrictions that the domain has on the attribute, like
disallowing version specifications.
This change just introduces the request and plumbs it through. NFC.
Now that most of the compiler tracks availability in terms of
AvailabilityDomain, it's time to do so in AvailabilityContext as well. This
will ensure that the compiler accurately suppresses diagnostics about a decl
being unavailable in an arbitrary domain when the context of the use is already
unavailable in that domain.
With this change, most of the special-casing for the Embedded Swift availability
domain has been removed from the compiler, outside of parsing and interface
printing.
This operation describes the partial ordering with which Availability domains
form a lattice.
As a temporary measure, a containment ordering needs to be specified for the
Swift language, Embedded, and Package Description domains. Without this
ordering, there won't be a way for AvailabilityContext to preserve the
invariant that the unavailable domain of a child context contains the
unavailable domain for the parent. However, once AvailabilityContext is
refactored to represent the status of multiple availability domains
simultaneously, the ordering of these domains relative to each other can be
relaxed.
NFC.
Most of the compiler should use SemanticAvailableAttr instead. In contexts like
ASTDumper where a semantic attribute is unavailable use accessors on
AvailableAttr.
NFC.
Follow-up from #78132, which did not fix issues related to eagerly imported members like subscripts.
This patch restructures recursive ClangRecordMemberLookup requests to importBaseMemberDecl() in the recursive calls, rather than propagating base member decls up to the initial lookup request and doing the import. Doing so seems to fix lingering resolution issues (which I've added to the regression tests).
rdar://141069984
As specified by the SE-0446 acceptance, extensions that declare a type's
conditional `Copyable` or `Escapable` ability must reiterate explicitly all
of the `Copyable` and/or `Escapable` requirements, whether required or not
required (by e.g. `~Copyable`) that were suppressed in the original
type declaration.
Since availability scopes may be built at arbitrary times, the builder may
encounter ASTs where SequenceExprs still exist and have not been folded, or it
may encounter folded SequenceExprs that have not been removed from the AST.
To avoid a double visit, track whether a SequenceExpr is folded and then
customize how ASTVisitor handles folded sequences.
Resolves rdar://142824799 and https://github.com/swiftlang/swift/issues/78567.
Access-level on imports is designed to downgrade the visibility of
imported decls. Add a check to apply this logic only to decls that were
originally visible: public and same-package.
rdar://143008763
Instantiating C++ function templates with Swift types is not currently supported, but the Swift compiler attempts to do so. Sometimes this leads to a compiler crash; other times it leads to a runtime crash. This patch turns those crashes into compiler errors.
At the call site of a C++ function template, the Swift compiler must convert Swift types deduced by the Swift type checker back into Clang types, which are then used to instantiate the C++ function template. Prior to this patch, this conversion was performed by ClangTypeConverter::convert(), which converts unsupported Swift types. This patch factors out some reusable parts of convert() and uses them in a new ClangTypeConverter::convertTemplateArgument() method that only converts supported template argument types. In the future, this method can be elaborated to support instantiating C++ templates with more types.
rdar://112692940
The issue here is that the demangler (since we have a postfix mangling) parses
parameters/results/etc and then uses earlier postfix type arguments to attach
the relevant types to the parameters/results/etc. Since the flag for a sending
result was placed in between the parameters and results, we get an off by one
error.
Rather than fix that specific issue by introducing an offset for the off by one
error, I used the fact that the impl-function part of the mangling is not ABI
and can be modified to move the bit used to signify a sending result to before
the parameters so the whole problem is avoided.
I also while I was doing this looked through the sending result mangling for any
further issues and fixed them as I found them.
rdar://141962865
Now that AvailableAttr has storage for its cached AvailabilityDomain, it's no
longer necessary to store an AvailabilityDomain inline in
SemanticAvailableAttr.
NFC.
This code got refactored and it accidentally widened the applicable structures for this check. The idea is that you have the following structure
// Module A
@_weakLinked import B
// Module B
@_exported import C
And the compiler conspires to make it so the modules B AND C wind up weak-linked from module A.
The broadened check accidentally allowed the following:
// Module A
@_weakLinked import B
// Module B
import C // Oops!
Which caused quite a few more modules than were intended to be weak-linked. Restore the `Exported` filter to cut back on the amount of weak re-exports the compiler processes.
Resolves rdar://142706779
Represent an AvailabilityDomain as a pointer union where one member of the
union is inline storage for built-in domains with known requirements and the
other member of the union is a pointer to an externally allocated domain
definition.
NFC.
Types annotated as `@_addressableForDependencies` are still usable by older
compilers that don't know about nonescapable types or lifetime dependencies,
since it only affects the behavior of the type when it's the source of a
dependency.
Check for unsafe conformances for type erasure and opaque type
erasure.
This also uncovered an issue where we were making every conformance of
an unsafe type to an unsafe protocol @unsafe implicitly, even though
that's not really what we want.
