Even if the final pattern ends up consuming the value, the match itself
must be nondestructive, because any match condition could fail and cause
us to have to go back to the original aggregate. For copyable values,
we can always copy our way out of consuming operations, but we don't
have that luxury for noncopyable types, so the entire match operation
has to be done as a borrow.
For address-only enums, this requires codifying part of our tag layout
algorithm in SIL, namely that an address-only enum will never use
spare bits or other overlapping storage for the enum tag. This allows
us to assume that `unchecked_take_enum_data_addr` is safely non-side-
effecting and match an address-only noncopyable enum as a borrow.
I put TODOs to remove defensive copies from various parts of our
copyable enum codegen, as well as to have the instruction report
its memory behavior as `None` when the projection is nondestructive,
but this disturbs SILGen for existing code in ways SIL passes aren't
yet ready for, so I'll leave those as is for now.
This patch is enough to get simple examples of noncopyable enum switches
to SILGen correctly. Additional work is necessary to stage in the binding
step of the pattern match; for a consuming switch, we'll need to end
the borrow(s) and then reproject the matched components so we can
consume them moving them into the owned bindings. The move-only checker
also needs to be updated because it currently always tries to convert
a switch into a consuming operation.
Introduce a new expression macro that produces an value of type
`(any AnyActor)?` that describes the current actor isolation. This
isolation will be `nil` in non-isolated code, and refer to either the
actor instance of shared global actor in other cases.
This is currently behind the experimental feature flag
OptionalIsolatedParameters.
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.
