The legacy, experimental SuppressedAssociatedTypes feature never
mangled any inverses into generic signatures of functions, nor mentioned
them in interfaces at all. In the new version of the feature that's been
officially accepted as SE-503, we now _do_ default primary associated
types to be Copyable & Escapable when they're suppressed. And we do mention
the suppressions in the interfaces as needed.
Rather than having the compiler mangle functions in two different ways,
this patch has the compiler be consistent about its mangling and interfaces,
regardless of which feature you're using.
This should mean that a future upgrade from the legacy feature to the
new one won't create an ABI break, only a source break (as expected).
So, an ABI change now before more people use the wrong experimental feature
will make it easier to migrate to the officially-accepted version later on.
rdar://170669869
Opaque return types are special type declarations that have it
own nested generic signature. Thus, given this:
```
protocol P<A> { associatedtype A: ~Copyable }
func f<T: ~Copyable>() -> some P<T> {}
```
The generic signature for f is <T where T Escapable>, and
for the opaque return type, its nested signature ends up as
```
<X where X: P, X.A == T>
```
With SE-503, we will now also expand a default for the suppressed
primary associated type, so the signature after expansion becomes
```
<X where X: P, X.A == T, X.A: Copyable>
```
It would be smarter to effectively have this rule
```
X.A == T, T: ~Copyable
----------------------
X.A: ~Copyable
```
where we infer the inverse on X.A to cancel-out the
expanded default X.A: Copyable. We already do this for
two in-scope type parameters, and it would be better if
we did it if one side was out-of-scope, but that would
be source-breaking to do in general.
In the case of opaque return types, the fact that
it has a nested generic signature seems more an
artifact of the implementation. There also is little
risk of source break, as the only kinds of same-type
requirements that can appear are from parameterized
protocol type.
The experimental suppressed associated types prior to
SE-503 wouldn't be broken by this change, as they do
not infer defaults that need suppression, and we only
filter-out requirements from defaults expansion, rather
than explicitly-written ones.
rdar://175500824
There's a need for more control over how default requirements
for conformance to Copyable/Escapable are expanded, and
subsequently how inverses are applied or inferred to cancel-out
those defaults.
The pattern of `/*applyInverses*/BOOL` is insufficient, so this
is a refactoring to grow that into a proper type that carries
an option that can be used in some future scenario about inferring
inverses for opaque return types.
Given that we implicitly expanded Copyable & Escapable
conformance requirements for suppressed primary associated
types, we now need this function to do the opposite;
filtering Copyable & Escapable requirements on such primary
associated types and adding inverses if those requirements
are missing.
This function plays a crucial role in emitting the interface
files accurately for functions and types, in addition to
how we mangle generic signatures into function symbols.
The mangling for generic signatures under the -WithDefaults version of
suppressed associated types goes like this:
- primary associated type T.A has an inverse `Rj` or `RJ` mangled
into the generic signature if it lacks the conformance, or
nothing is mangled into it.
- non-primary associated type T.B has either a `T.B: Copyable`
requirement mangled into it, or nothing is mangled into it.
For the legacy SuppressedAssociatedTypes feature, where there's no
defaults, it uses the "non-primary assocated type" mangling strategy
for all generic signatures.
If we failed to construct a rewrite system for a protocol, either because
the Knuth-Bendix algorithm failed or because of a request cycle while
resolving requirements, we would end up in a situation where the resulting
rewrite system didn't include all conformance requirements and associated
types, so name lookup would find declarations whose interface types are
not valid type parameters.
Fix this by propagating failure better and just doing nothing in
getReducedTypeParameter().
Fixes rdar://147277543.
While the intent behind this functor was noble, it has grown in complexity
considerably over the years, and it seems to be nothing but a source of
crashes in practice. I don't want to deal with it anymore, so I've decided
to just subsume all usages with LookUpConformanceInModule instead.
Key paths can't reference non-escapable or non-copyable storage declarations,
so we don't need to refer to them resiliently, and can elide their property
descriptors.
However, declarations may still be conditionally Copyable and Escapable, and
if so, then they still need a property descriptor for resilient key path
references. When a property or subscript can be used in a context where it
is fully Copyable and Escapable, emit the property descriptor in a generic
environment constrained by the necessary conditional constraints.
Fixes rdar://151628396.
Convert a bunch of places where we're dumping to stderr and calling
`abort` over to using `ABORT` such that the message gets printed to
the pretty stack trace. This ensures it gets picked up by
CrashReporter.
This is going to need a proper implementation in the requirement
machine. For the moment, provide a slightly-less-broken implementation
but leave a test case where we incorrectly accept racey code.
I added commit 7eecf97132 a while ago
to fix a newly-added assertion failure that came up, however this
had the inadvertent side effect of changing symbol mangling and
ASTPrinter behavior.
The problem in both instances was that we would incorrectly return
certain requirements as unsatisfied when really they are satisfied.
There is nothing to fix in the ASTPrinter, because printing redundant
requirements does not change the generic signature of the extension;
they are simply dropped. I added a test to exercise the new behavior
showing that the requirements are dropped.
As for the mangler, the fix introduced an ABI break, because the
symbol name of a conformance descriptor includes its conditional
requirements, so we must preserve the redundant requirements forever.
The IRGen test has some examples of manglings that are incorrect but
must be preserved.
I'm plumbing down a flag to isRequirementSatified() to preserve
compatibility with the old behavior where we would mangle these
redundant requirements. No other callers should pass this flag,
except for the mangler.
Fixes rdar://139089004.
This is a silly "extended" verification check that we only exercise
in test/Generics/validate_stdlib_generic_signatures.swift.
We were taking a requirement containing unbound dependent member types
and applying a substitution map to it, which would result in an
ErrorType, so the requirement was always considered unsatisfied here
and the check was not as useful as it should have been.
Instead, re-implement a version of isRequirementSatisfied() that only
uses generic signature queries instead of substitution here.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
For new runtimes, this is redundant with the invertible requirement encoding, and for
old runtimes, this breaks dynamic conformance checking because Copyable and Escapable
aren't real protocols on those older runtimes. Fixes rdar://129857284.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
When a NoncopyableGenericsMismatch happens between the compiler and
stdlib, allow the compiler to rebuild the stdlib from its interface
instead of exiting with an error.
rdar://121071710
Currently it uses builtin integers, which round up to the next power of 2, which is not what we want here. Instead it should use builtin vectors of uint8 and a number of elements equal to the stride in bytes.
rdar://119329771
This layout allows adding pre-specializations for trivial types that have a different size, but the same stride. This is especially useful for collections, where the stride is the important factor.
* [SILOpt] Allow pre-specializations for _Trivial of known size
rdar://119224542
This allows pre-specializations to be generated and applied for trivial types of a shared size.