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.
Function body macros allow one to introduce a function body for a
particular function, either providing a body for a function that
doesn't have one, or wholesale replacing the body of a function that
was written with a new one.
To match the swiftinterfaces that are emitted for eagerly typechecked ASTs,
lazily trigger initializer expression typechecking for typed patterns that were
written using a typealias.
Resolves rdar://118698233
After review, Slava and I decided it's not a good idea to provide a
`TypeBase::getAnyTypeDecl` method, as it is not typically what people
generally should use, as it doesn't handle all cases (type parameters
with no associated decl, for example).
There's no reason to generate only TypeRepr using ASTGen anymore.
Use ParserASTGen feature to test test/ASTGen/types.swift because
ASTGen now can generate the whole test file for type checking.
Declarations may have semantic actor isolation requirements that were not
written in source. For example, the default implementation of a protocol
requirement must be `@MainActor` isolated if the protocol declaration itself is
`@MainActor` isolated. When computing the semantic attributes of a declaration
lazily, we must compute the actor isolation of the declaration to ensure that
any global actor constraint attributes are added.
Also, avoid request cycles and recursive diagnostic printing by only triggering
the computation of semantic attributes when printing for swiftinterfaces.
Resolves rdar://118277555
