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.
Our Bazel builds have become more strict about libc++
dependencies recently, so these are required to pick up
declarations of `malloc` and `uint32_t`, respectively.
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
Also stop suggesting a '?' fix-it for casts, where it is not likely to
be helpful because the common intention is either to force the optional
or declare an IUO.
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.
AvailabilityConstraint models a superset of UnavailabilityDiagnosticInfo and
will become the currency type for unsatisfied availability everywhere. NFC.
This failure will most-likely result in the dependency query failure which will fail the scan. It will be helpful if the scanner emitted diagnostic for each such module it rejected to explain the reason why.
Resolves rdar://142906530
When building the runtime we define `SWIFT_RUNTIME`. `swiftCore_EXPORTS`
is only defined when building swiftCore as a shared library. This would
thus allow the ODR violations to appear in a static library form of the
standard library. This was uncovered with the new runtime build system.
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.
We're not planning on removing the splitter because it is a big win
in some cases, but we want to run it less often since it can also
be a source of overhead. This flag allows us to compare performance
to understand the tradeoffs better.
Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
Diagnostics may be emitted while parsing command line arguments. This implies
that the options which affect how diagnostics are emitted and presented need to
be parsed first.
This adjusts the runtime function declaration handling to track the
owning module for the well known functions. This allows us to ensure
that we are able to properly identify if the symbol should be imported
or not when building the shared libraries. This will require a
subsequent tweak to allow for checking for static library linkage to
ensure that we do not mark the symbol as DLLImport when doing static
linking.
Expose a `Task`'s resume context via the `AsyncTaskInfo` struct.
This will be used by lldb, but since this data is not specific to lldb it seems reasonable to include it generally.
