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.
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
This basically undoes 3da6fe9c0d, which in hindsight was wrong.
There were no other usages of TypeArrayView anywhere else except for
GenericSignature::getGenericParams(), and it was almost never what
you want, so callers had to convert back and forth to an ArrayRef.
Remove it.
Only preserve primary associated types during type erasure if the
generic context does not contain outer generic prameters.
i.e.
Given `func foo { ... any P <Int> ... }` getNonDependentUpperBounds()
should produce any P<Int>
However, given `func foo<T> { ... any P<T> ... }` getNonDependentUpperBounds()
should produce any P
Fixes rdar://110262754
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
When completing, we call `getExistentialType` on the contextual type to get a nice and concise description of the contextual parameter’s type that doesn’t contain archetypes and which we can also serialize into a USR so we are able to calculate type relations for code completion results from the code completion cache.
When completing in a position that has a contextual type which only constrains one of two primary associated protocol types, this fails because `getExistentialType` (which calls `getDependentUpperBounds`) tries to form a `ParameterizedProtocolType`, which fails since not all primary associated types have been constrained.
AFAICT the fix here is to just fall back to the default behavior of returning the plain protocol type instead of `abort`ing.
rdar://108835466
This simplifies the representation and allows clients to handle fewer
cases. It also removes an ambiguity in the representation which could
lead us to have two canonical types for the same type.
This is definitely not working yet, but I'm not making progress on
it quickly enough to unblock what we need to unblock; it'll have to
be fixed in parallel.
