In some cases, like when building the Swift toolchain build tools,
`SWIFT_STDLIB_LIBRARY_BUILD_TYPES` is not defined. This causes a
configuration failure when the `CompatibilitySpan` library is being
added.
This commit sets a default value of `STATIC` to work around this
problem.
Replace this direct use of the count in a table header as the upper
bound of a for loop with a range-based for loop over the range which was
being indexed into. That range was constructed using that count to
begin with.
Rather than pass a MethodOverrideDescriptor directly, instead pass the
fields from it that are needed by the callee. In preparation for adding
another caller which doesn't have a MethodOverrideDescriptor.
This replaces `strdup` with `_strdup` on Windows to avoid the POSIX API
deprecation warnings. It also does a minor simplification by removing
the superfluous `else`.
This dynamic library contains a copy of the standard library's
exported entry points for the Span and RawSpan types. This will
allow backward deployment of code that uses those new types.
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.
