If the substitution terms of a concrete type symbol contain unresolved
name symbols, we have an invalid requirement that is dropped from the
minimized signature. In this case, the rewrite system used for minimization
cannot be installed as the official rewrite system for this generic
signature, because building a rewrite system from the signature will
produce a different result.
This might be the cause of the crash in rdar://114111159.
Sink down the null Decl printing into
`printDeclDescription` such that all callers
benefit from it.
This is an attempt at fixing at least the secondary
crash in rdar://113491294, it does not address the
underlying crash.
Pre-macro-expansion conformances are introduced at the point where an
attached extension macro is attached to a particular nominal type, and
can imply other conformances. Once the macro is expanded, they are
expected to be replaced by the real conformance from the extension
produced by the macro. This includes any other conformances that are
implied by that conformances. Ensure that the real conformance---and
every conformances it implies---are considered "better" than the
pre-expansion conformances.
Fixes a bug where we would pick the wrong (pre-expansion)
conformances, which would then fail to get fully type-checked prior to
serialization. This could accept invalid code that then crashed the
compiler, as in rdar://112916159.
Type-checking patterns is not fully requestified, so the
ASTPrinter should not assume this has been filled in.
It appears sufficient to just visit the associated VarDecl,
as we do already.
dependencies
It is valuable for clients to be able to distinguish which dependencies of a
Swift module originated from 'import' statements, and which ones are implicit
dependency Swift overlays of imported Clang modules.
And add a comment explaining why this check is only relevant to protocols, and shouldn't
be copied to other similar-looking isResilient methods on other types.
According to 25376025ae, which introduced the original
`@_originallyDefinedIn` check, this check was necessary to maintain ABI compatibility
when protocol declarations are moved, but in all other cases, we should treat declarations
as resilient when they are defined in other library-evolution-enabled modules, even when
the declaration was originally defined in the current module.
Fix two inter-related issues with extension macros that provide
conformances to a protocol, the combined effect of which is that one
cannot meaningfully provide extension macros that implement
conformances to a protocol like Equatable or Hashable that also
supports auto-synthesis.
The first issue involves name lookup of operators provided by macro
expansions. The logic for performing qualified lookup in addition to
unqualified lookup (for operators) did not account for extension
macros in the same manner as it did for member macros, so we would not
find a macro-produced operator (such as operator==) in witness
matching.
The second issue is more fundamental, which is that the conformance
lookup table would create `NormalProtocolConformance` instances for
pre-macro-expansion conformance entries, even though these should
always have been superseded by explicit conformances within the macro
expansion buffers. The end result is that we could end up with two
`NormalProtocolConformance` records for the same conformance. Some
code was taught to ignore the pre-expansion placeholder conformances,
other code was not. Instead, we now refuse to create a
`NormalProtocolConformance` for the pre-expansion entries, and remove
all of the special-case checks for this, so we always using the
superseding explicit conformances produced by the macro expansions (or
error if the macros don't produce them).
Fixes rdar://113994346 / https://github.com/apple/swift/issues/66348
This logic may override the module considered as the source of a decl to
ensure that only visible modules are printed in the swiftinterface. This
change updates it to consider @_spiOnly imported modules from the local
module as visible when printing the private swiftinterface only.
rdar://103325332
This reverts commit d5b354fd5f. It causes miscompiles when
accessing properties declared with `@_originallyDefinedIn` that are now defined in modules
with library evolution enabled from the module that the property was originally defined in.
Just because the property used to be declared in the current module doesn't mean it can
bypass the stable ABI of the module that the property now belongs to.
It looks like the logic that this PR replaced is also faulty, since `@_originallyDefinedIn`
really oughtn't factor into the resilience computation at any level, but let's unwind one
level of brokenness at a time.
Fixes rdar://113935401.
There aren't sufficiently strong compiler checks that would prevent unavailable
elements of clang enums from being instantiated at runtime, so don't consider
any clang enum elements as unavailable during lowering. Since there aren't any
symbols associated with clang enum elements, we don't have to worry about
linker failures that might result from leaving references to them in SIL.
Cache a bit on `EnumDecl` indicating whether there are any elements that are
unavailable during lowering and then use that bit to decided whether to attempt
optimization for `switch_enum`/`switch_enum_addr` instructions.
A temporary fix to make it possible to debug expressions
with partially resolved variadic generic types. The issue stems
from the fact that `BoundGenericType` is allowed to have pack
parameters directly represented by type variables, as soon as
that is no longer the case this check should be removed.
The cached values for `hasOnlyCasesWithoutAssociatedValues()` and
`hasPotentiallyUnavailableCaseValue()` are computed in a single pass over the
elements of an `EnumDecl`. However, the pass would return early after finding
an element with an associated value, without checking whether any of the rest
of the elements were potentially unavailable. This made `Comparable` synthesis
succeed for any enum with potentially unavailable elements so long as the first
element in the enum has an associated value.
This will be used to provide a safe overload of `std::vector::erase` in Swift.
`std::vector::erase` is not currently imported into Swift because it returns a C++ iterator.
rdar://113704853
Instead of the code querying the compiler's built-in Clang instance, refactor the
dependency scanner to explicitly keep track of module output path. It is still
set according to '-module-cache-path' as it has been prior to this change, but
now the scanner can use a different module cache for scanning PCMs, as specified
with '-clang-scanner-module-cache-path', without affecting module output path.
Resolves rdar://113222853
