In cases where the generic parameter is class-constrained,
`GenericSignature::requiresProtocol` will not contain `Copyable` or
`Escapable` because GenericSignature minimization will recognize that
the class already requires them.
Thus, because classes always require those protocols, we can
simply ask if the generic parameter is required to be a class to
determine if it had any inverses.
Merge `$<Feature>` and `hasFeature` implementations.
- `$<Feature>` did not support upcoming language features.
- `hasFeature` did not support promoted language features and also
didn't take into account `Options` in `Features.def`.
Remove `Options` entirely, it was always one of three cases:
- `true`
- `langOpts.hasFeature`
- `hasSwiftSwiftParser`
Since `LangOptions::hasFeature` should always be used anyway, it's no
longer necessary. `hasSwiftSwiftParser` can be special cased when adding
the default promoted language features (by removing those features).
Resolves rdar://117917456.
I am doing this in preparation for adding options to SILParameterInfo/
SILResultInfo that state that a parameter/result is transferring. Even though I
could have just introduced a new bit here, I instead streamlined the interface
of SILParameterInfo/SILResultInfo to use an OptionSet instead of individual bits
to make it easier to add new flags here. The reason why it is easier is that
along API (e.x.: function argument) boundaries one does not have to marshal each
field or pass each field. Instead one can just pass the whole OptionSet as an
opaque thing. Using this I was able to change serialization/deserialization of
SILParameterInfo/SILResultInfo so that one does not need to update them if one
adds new fields!
The reason why I am doing this for both SILParameterInfo/SILResultInfo in the
same commit is because they share code in the demangler that I did not want to
have to duplicate in an intervening commit. By changing them both at the same
type, I didn't have to change anything without an actual need to.
I am doing this in a separate commit from adding transferring support so I can
validate correctness using the tests for the options already supported
(currently only differentiability).
While printing them as `some P` makes sense in the AST since they
only ever appear at their definition point, in the body of a SIL
function, opaque parameter types can be referenced by various
instructions, like any other generic parameter type.
Instead of printing out `some P` or `<anonymous>` depending on
context, neither of which actually parsed, instead print them
with the canonical type `τ_d_i` notation. Since it's printed this
way in the generic parameter list as well, it parses back in.
Fixes rdar://problem/119823811.
Follow the feature flag convention for capitalization and be
consistent with the related NoncopyableGenerics feature.
This is a new feature that no wild Swift code has used it yet:
commit e99ce1cc5d
Author: Kavon Farvardin <kfarvardin@apple.com>
Date: Tue Dec 5 23:25:09 2023
[NCGenerics] add `~Escapable`
Basic implementation of `~Escapable` in the type system.
TypeDecl::canBeNoncopyable is never going to be fully accurate. In this
instance, we were incorrectly treating some types like `S<T: ~Copyable>`
as noncopyable, and thus non-trivial, despite them in some cases being
Copyable.
We can't simply emit the desugared, expanded version of the requirements
because there's no way to pretty-print the type `some ~Copyable` when
the `~Copyable`'s get replaced with the absence of `Copyable`. We'd be
left with just `some _` or need to invent a new top type so we can write
`some Top`. Thus, it's best to simply reverse the expansion of default
requirements when emitting a swiftinterface file.
The number of errors in a function scope can scale exponentially,
making it hard to root cause and resolve unless we group them into
a single error. Grouping the error diagnostics will considerably
improve the concurrency user experience.
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.
The errorUnion type operation specifies how thrown error types are
combined when multiple errors are thrown in the same context. When
thrown error types can have type variables in them, we sometimes cannot
resolve the errorUnion until the type variables have substitutions. In
such cases, we need to persist the result of errorUnion in the
constraint solver.
Introduce the ErrorUnionType to do exactly that, and update the core
errorUnion operation to produce an ErrorUnionType when needed. At
present, this code is inert, because any errorUnion operation today
involves only concrete types. However, inference of thrown errors in
closures will introduce type variables, and depend on this.
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
