@_transparent will ensure there are inlined in MandatoryInlining which runs before OSLogOptimization.
OSLogOptimization does not look through their calls because they are not marked with
@_semantics("constant_evaluable") which requires them to also be annotated as @_optimize(none)
rdar://148256435
The integer conversion operations were inlinable, but aren't getting
inlined in debug builds, which results in unreasonably poor
performance. Mark them as transparent so we don't end up with
unspecialized generic code in the hot path.
Fixes https://github.com/swiftlang/swift/issues/78501
* [stdlib] Remove docs from default implementations
Customized docs were not removed:
public static var isSigned: Bool
public static var max: Self
public static var min: Self
public var description: String
public var magnitude: Self
public init<T: BinaryInteger>(_ source: T)
public func distance(to other: Self) -> Int
public func advanced(by n: Int) -> Self
* [stdlib] Remove unused docs for "unsafe" methods
* [stdlib] Remove inherited "ReportingOverflow" docs
* [stdlib] Remove inherited docs for operators
Customized docs were not removed.
(`+`, `-`, `*`, `+=`, `-=`, `*=`)
Non-inherited docs were not removed.
(`&+`, `&-`, `&+=`, `&-=`, `&*=`)
* [stdlib] Reattach doc comments to their APIs
Use `rstrip()` to remove the trailing newline.
<https://docs.python.org/3/library/stdtypes.html#str.rstrip>
* [stdlib] Remove inherited docs from integer types
* [stdlib] Remove FIXME(ABI) comments
* [stdlib] Remove unused docs for operators
* [stdlib] Update example code for `-=` and `*=`
* [stdlib] Update internal gyb comments
* [stdlib] Move docs to BinaryInteger overrides
* [stdlib] Remove unused gyb code
* [stdlib] Fix `&-` and `&*` examples
These are provided for FixedWidthInteger & UnsignedInteger (the base implementation, following Knuth's Algorithm D) and SignedInteger (converting to magnitudes and calling the former). Previously no default implementations were available, requiring every type to implement these operations.
These defaults will not be optimal for large fixed-width integers, so types vending Int512 or similar integers should still provide their own implementations, but they are unconditionally available as a fallback, which simplifies the process of writing such types, and work well enough as a fallback for modest fixed-width integer types like Int64 or 32b or smaller platforms or Int128 on 64b platforms.
Additionally rework the concrete implementations to guarantee that we always trap when the quotient is not representable, and to improve performance for 64b integers on arm64_32, and added some new test coverage for these operations.
This isn't a "complete" port of the standard library for embedded Swift, but
something that should serve as a starting point for further iterations on the
stdlib.
- General CMake logic for building a library as ".swiftmodule only" (ONLY_SWIFTMODULE).
- CMake logic in stdlib/public/core/CMakeLists.txt to start building the embedded stdlib for a handful of hardcoded target triples.
- Lots of annotations throughout the standard library to make types, functions, protocols unavailable in embedded Swift (@_unavailableInEmbedded).
- Mainly this is about stdlib functionality that relies on existentials, type erasure, metatypes, reflection, string interpolations.
- We rely on function body removal of unavailable functions to eliminate the actual problematic SIL code (existentials).
- Many .swift files are not included in the compilation of embedded stdlib at all, to simplify the scope of the annotations.
- EmbeddedStubs.swift is used to stub out (as unavailable and fatalError'd) the missing functionality.
These were defined for both FixedWidthInteger and FixedWidthInteger & SignedInteger for source compatibility with Swift 3; the latter set probably should have been removed when we stabilized the ABI, but were not. We can't easily remove them entirely (because we need them for ABI stability now), but we can mark them unavailable so that the typechecker doesn't have to consider them..
Previously we said that a type conforming to SignedNumeric allows positive and negative values, but that's nonsense. A type conforms to signed numeric if it has a negate() operation; it doesn't even have to have a notion of positive or negative values (for examples, see complex numbers, quaternions, integers mod n, etc).
There's nothing useful to say about the type of .zero -- it's
constrained by the protocol to Self, so you don't have any choice what
it is when conforming to AdditiveArithmetic.
Fixes <rdar://problem/72592923> (SR-13983).
Allow the closed-range version of `FixedWidthInteger.random(in:using:)` to work for types larger than 64 bits when the entire valid range (`.min ... .max`) is passed in.
Also, closed ranges are never empty, so the unnecessary `!isEmpty` precondition has been removed.
