In addition to skipping it on textual Swift module dependencies which were built without C++ interop enabled, also skip it over similarly on binary Swift dependencies
Get rid of the boolean arguments for unavailability in AvailabilityQuery's
constructors and introduce a `asUnavailable()` modifier that can be used
instead in the contexts where unavailability is relevant.
Conditionally available opaque return types should support availability
conditions that are evaluated in any availability domain. Update
`ConditionallyAvailableSubstitutions` to model its conditions with
`AvailabilityQuery` instead of assuming that conditions are always a single
version query for the current platform.
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
There is no debug output from the `CompareDeclSpecializationRequest`
because the flag that enables it is not passed down from the primary
constraint system.
Since this is a source breaking change, downgrade the diagnostic to a warning
until the next language version unless library evolution is enabled, in which
case this would have resulted in a broken `.swiftinterface` and it therefore
makes sense to diagnose eagerly.
Resolves rdar://156919010.
Protocol requirement witnesses cannot only be available in a custom
availability domain if the requirement does not have the same availability
constraint.
Resolves rdar://156462516.
Since this is a C++ stdlib type we need make sure that any overloads
that use it are preferred over custom types that also conform to
`ExpressibleByStringLiteral` when argument is a string literal.
This is important for operators like `==` which could be heterogenous
and have a custom C++ type that conforms to `ExpressibleByStringLiteral`
on either side together with `std.string` i.e.
`==(std.string, const CustomString &)`, such overloads should only
be selected if argument passed to `CustomString` is non-literal because
literals are convered by a stdlib `==(std.string, std.string)` overload.
This is required in order to always have computed the set of visible Clang modules for each Swift module in the graph. Otherwise when some Clang module gets cached as a transitive dependency from a query and is later looked up as a direct dependency, there will not be any computed visible modules set.
Previously Swift overlay lookup was performed for every directly and transitively-imported Clang module.
https://github.com/llvm/llvm-project/pull/147969 introduced the concept of "visible" Clang modules from a given named Clang dependency scanner query which closely maps to the set of modules for which Swift will attempt to load a Swift overlay. This change switches overlay querying to apply only to the set of such visible modules.
Resolves rdar://144797648
Consolidate some of the closely related protocol requirement check failures and
then turn `RequirementCheck` into a proper wrapper around a union of associated
values for `CheckKind`.
NFC.
Add a new option `-gen-reproducer` that when swift caching is used,
create a standalone reproducer that can be used to reproduce the
`swift-frontend` invocation.
A substitution map contains conformances, and a conformance can contain
a substitution map. This will always be a DAG, but not a tree, and to
avoid exponential blowup in certain edge cases, let's cache the work to
avoid visiting the same substitution map repeatedly, if multiple
conformances refer to the same substitution map.
