This is just to round things out — this internal function was sticking out from the public interfaces. No stdlib code needs this generalization yet, but I see no reason to delay it.
`func type(of:)` is wholly magical, but it does have a signature in the stdlib (mostly for documentation purposes), and it currently requires its input to be copyable and escapable.
`type(of:)` is actually usable on all entities, so it seems desirable to update its signature to reflect this.
Additionally, this seems like a good time to mark its exported symbol obsolete. I don’t expect anyone would ever link to it (unless there is/was a bug), so in theory we could also silently remove it — but explicitly marking it as legacy ABI seems the least risky option.
We cannot currently express its proper lifetime semantics: its result’s lifetime should depend on the intersection of the lifetime of the left argument and the lifetime of the result of the right argument.
`@lifetime(optional, defaultValue.result)` is what we want, but the `.result` part is not currently expressible. (Tying the dependency on the closure argument itself may be a viable option, but we aren’t confident enough to ship it like that yet.)
`Slice` continues to require `Element` to be copyable, so this is limited to`moveInitializeMemory`, `bindMemory`, `withMemoryRebound` and `assumingMemoryBound`. Generalizing these restores parity with the corresponding operations on unsliced buffer pointers, and reduces the need to artificially rebase the slices only to call these.
We have a few constructor functions that aren't wrapped in SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_BEGIN/SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_END and which have started to produce warnings in a new clang version. Explicitly allow these constructors by adding those.
rdar://147703947
This fixes a `copy constructor must pass its first argument by reference` compilation error when compiled with a recent enough Clang (after fe0d3e3764)
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
Android should use the dispatch based, Linux platform executor. However,
Android reports as `os(Android)` rather than `os(Linux)`. This adjusts
the condition to ensure that we have a platform executor factory for
Android.
These were split out in #79751. However, this split is not needed for
these. Furthermore, modulemaps have bugs when it comes to re-exporting
some modules, resulting in missing exports.
