Inspired by #84826, I've dusted off and completely reworked a native
implementation of integer-to-string conversion.
Besides existing tests in this repository, the core of the
implementation has been comprehensively tested in a separate package for
all bases between 2–36 to demonstrate identical output for all 8-bit and
16-bit values, and for randomly generated 32-bit, 64-bit, and 128-bit
values.
Resolves#51902.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
Optimize (the very inefficient) RawRepresentable comparison function call to a simple compare of enum tags.
For example,
```
enum E: String {
case a, b, c
}
```
is compared by getting the raw values of both operands and doing a string compare.
This peephole optimizations replaces the call to such a comparison function with a direct compare of the enum tags, which boils down to a single integer comparison instruction.
rdar://151788987
The new generalization sometimes causes a runtime hang that I’m still analyzing. The original declaration should be considered more specific for preexisting use cases, eliminating the source compatibility issue.
`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.)
Introduce a marker protocol SendableMetatype that is used to indicate
when the metatype of a type will conform to Sendable. Specifically,
`T: SendableMetatype` implies `T.Type: Sendable`. When strict
metatype sendability is enabled, metatypes are only sendable when `T:
SendableMetatype`.
All nominal types implicitly conform to `SendableMetatype`, as do the
various builtin types, function types, etc. The `Sendable` marker
protocol now inherits from `SendableMetatype`, so that `T: Sendable`
implies `T.Type: Sendable`.
Thank you Slava for the excellent idea!
This PR adds basic support for storing lifetime dependence information,
transform Span return types, and generate lifetime annotations.
rdar://139074571
* Import __counted_by for function return values
Instead of simply passing a parameter index to _SwiftifyInfo, the
_SwiftifyExpr enum is introduced. It currently has two cases:
- .param(index: Int), corresponding to the previous parameter index
- .return, corresponding to the function's return value.
ClangImporter is also updated to pass this new information along to
_SwiftifyImport, allowing overloads with buffer pointer return types to
be generated. The swiftified return values currently return Span when
the return value is marked as nonescaping, despite this not being sound.
This is a bug that will be fixed in the next commit, as the issue is
greater than just for return values.
* Fix Span variant selection
There was an assumption that all converted pointers were either
converted to Span-family pointers, or UnsafeBufferPointer-family
pointers. This was not consistently handled, resulting in violating the
`assert(nonescaping)` assert when the two were mixed. This patch removes
the Variant struct, and instead each swiftified pointer separately
tracks whether it should map to Span or UnsafeBufferPointer.
This also fixes return pointers being incorrectly mapped to Span when
marked as nonescaping.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
We used to treat 'rethrows' like an attribute, printing it as
'@rethrows', which was incorrect. That's fixed now, so update the
API/ABI checker tests to account for that.
