We want a conditionally-copyable type to still be classified as trivial in cases
where it's bitwise-copyable, has a trivial deinit, and is Copyable. The previous
implementation here only checked at the declaration level whether a type was
Copyable or not; get a more accurate answer by consulting the combination
of information in the substituted type and abstraction pattern we have
available during type lowering so that we classify definitely-copyable substitutions
of a conditionally-copyable type as trivial. Should fix rdar://123654553 and
rdar://123658878.
With NoncopyableGenerics, we get a cycle involving
`SuperclassTypeRequest` with this program:
public struct RawMarkupHeader {}
final class RawMarkup: ManagedBuffer<RawMarkupHeader, RawMarkup> { }
Because we generally don't support the following kind of relationship:
class Base<T: P>: P {}
class Derived: Base<Derived> {}
This commit works around the root-cause, which is that Derived's
synthesized conformance to Copyable gets superceded by the inherited one
from Base. Instead of recording conformances in the ConformanceLookup
table at all, create builtin conformances on the fly, since classes
cannot be conditionally Copyable or Escapable.
There's a few uses of ReferenceStorageTypes being substituted for
generic parameters, at least in the test suite, such as
`Optional<@sil_unmanaged ..>` and just plain `<@sil_unowned ..>`.
Before, conformance lookup could (and did) give bogus answers when asked
if the type satisfies any conformance requirements. Now with
NoncopyableGenerics, we will interpret such conformance lookups as
being asked of the referent type, ignoring the SIL ownership wrapping
it.
I thought it might be impossible to recursively lookupConformance of
Copyable, unlike for Sendable. Turns out there are still situations
where it can happen, that aren't invalid.
This alone fixes `ClangImporter/objc_bridging_generics.swift` and will
help reveal any invalid request cycles.
I thought this would be simple to add a check for this, but it turns out
that a more complete refactoring that eliminates `isNoEscape` in favor
of `isEscapable` is most likely needed.
An unbound generic type is not something that should end up in
`isNoncopyable` or `isEscapable` queries because there are no
conformances for such a type; it's unbound!
fixes test/Constraints/closures.swift
First, "can have an absence of Copyable" is a rather confusing notion,
so the query is flipped to "can be Copyable". Next, it's more robust to
ask if a conformance exists for the TypeDecl to answer that question,
rather than trying to replicate what happens within that conformance
lookup.
Also renames `TypeDecl::isEscapable` to match.
