`@noDerivative` was not mangled in function types, and was resolved incorrectly when there's an ownership specifier. It is fixed by this patch with the following changes:
* Add `NoDerivative` demangle node represented by a `k` operator.
```
list-type ::= type identifier? 'k'? 'z'? 'h'? 'n'? 'd'? // type with optional label, '@noDerivative', inout convention, shared convention, owned convention, and variadic specifier
```
* Fix `NoDerivative`'s overflown offset in `ParameterTypeFlags` (`7` -> `6`).
* In type decoder and type resolver where attributed type nodes are processed, add support for nested attributed nodes, e.g. `inout @noDerivative T`.
* Add `TypeResolverContext::InoutFunctionInput` so that when we resolve an `inout @noDerivative T` parameter, the `@noDerivative T` checking logic won't get a `TypeResolverContext::None` set by the caller.
Resolves rdar://75916833.
* Move differentiability kinds from target function type metadata to trailing objects so that we don't exhaust all remaining bits of function type metadata.
* Differentiability kind is now stored in a tail-allocated word when function type flags say it's differentiable, located immediately after the normal function type metadata's contents (with proper alignment in between).
* Add new runtime function `swift_getFunctionTypeMetadataDifferentiable` which handles differentiable function types.
* Fix mangling of different differentiability kinds in function types. Mangle it like `ConcurrentFunctionType` so that we can drop special cases for escaping functions.
```
function-signature ::= params-type params-type async? sendable? throws? differentiable? // results and parameters
...
differentiable ::= 'jf' // @differentiable(_forward) on function type
differentiable ::= 'jr' // @differentiable(reverse) on function type
differentiable ::= 'jd' // @differentiable on function type
differentiable ::= 'jl' // @differentiable(_linear) on function type
```
Resolves rdar://75240064.
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
Since libDemangling is included in the Swift standard library,
ODR violations can occur on platforms that allow statically
linking stdlib if Swift code is linked with other compiler
libraries that also transitively pull in libDemangling, and if
the stdlib version and compiler version do not match exactly
(even down to commit drift between releases). This lets the
runtime conditionally segregate its copies of the libDemangling
symbols from those in the compiler using an inline namespace
without affecting usage throughout source.
This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
TypeRefBuilder and MetadataReader had nearly identical symbolic reference resolvers,
but diverged because TypeRefBuilder had its own local/remote address management mechanism,
and because TypeRefBuilder tries to resolve opaque types to their underlying types, whereas
other MetadataReader clients want to preserve them as written in source. The first problem
has been addressed by making TypeRefBuilder use `RemoteRef` everywhere, and the second
can be handled with a flag (and might be able to be handled more elegantly with some more
refactoring of general opaque type handling in MetadataReader).
The Remote Mirror interop header now accepts an arbitrary number of remote mirror libraries so that it can have 4.1, 4.2, and 5.0 loaded side by side.
rdar://problem/45808282
Right now we expect that every class and protocol has a field
descriptor that tells us if the entity is @objc or not.
For imported types, the descriptor will not exist if we did not
directly emit a field whose concrete type contains the imported
type. For example, in lldb, we might have a generic type whose
runtime substituted type includes an imported type.
In this case, TypeLowering would fail to produce a layout because
it did not find a field descriptor for the imported type.
A better approach is to have the TypeDecoder call a different
factory method for imported types, and handle them specially in
TypeLowering, bypassing the field type metadata altogether.
TypeDecoder's interface with its builders already treated protocols as
a type (due to their being mangled as "protocol composition containing
one type"), and intermixed protocols with superclasses when forming
compositions. This makes for some awkwardness when working with
protocol descriptors, which are very much a distinct entity from a
type.
Separate out the notion of a "protocol declaration" (now represented
by the builder-provided BuiltProtocolDecl type) from "a protocol
composition containing a single type", similarly to the way we handle
nominal type declarations. Teach remote mirrors and remote AST to
handle the new contract.
Somehow ninja didn't rebuild everything, so I ended up pushing code
that didn't compile. I did a clean re-build and fixed a minor issue
in the logic, now the test passes.
When deriving substitutions from closure contexts, we end up with
a problem where we have an original type and a substituted type,
and the original type is not necessarily a type parameter.
We need to decompose the original and substituted types to derive
the substitutions that produced the substitution.
For example, deriveSubstitutions(Foo<T -> Int>, Foo<String -> Int>)
will give us a substitution of T := Int.
