- Fix error in `last(where:)` example
- Improve MemoryLayout, UnsafePointer, and integer operator discussions
- Clean up ranges and random APIs
- Revisions to overflow operators and the SignedNumeric requirements
- Standardize on 'nonoptional' in remaining uses
Returning `Self` was probably a hack from when shifts were required to be homogenous and we didn't have good generic inits between integer types. Returning Int is more natural, because:
1. Dimensional analysis says that we shouldn't expect the logarithm to have the same type.
2. Int is guaranteed to be able to represent any object size, and BinaryInteger does not admit sparse representations, so the logarithm of the value cannot exceed allocated storage size.
3. Every single use case in the stdlib and tests is either unchanged or simplified by this change.
- Revise Bool.toggle() discussion and fix attribute placement
- Revise to Hasher abstracts and discussions
- Correct the name of the remainder operator
- Clean up deprecations and paste-os w/in UnsafePointer
Improvements from SE-0213 made constant propagation more
precise but, as a side-effect, resulted in more false positives,
to mitigate that `magnitude` has marked as `@inline(__always)`
but it could be made transparent again by using `&+` operator.
Implementation is as follows: In `preCheckExpression` try to
detect if there is `T(literal)` call in the AST, replace it with
implicit `literal as T`, while trying to form type-checked AST,
after constraint solving, restore source information and drop
unnecessary coercion expression.
Resolves: rdar://problem/17088188
Resolves: rdar://problem/39120081
Resolves: rdar://problem/23672697
Resolves: rdar://problem/40379985
LLVM specifies that the result of fptosi and fptoui instructions are
undefined if the target type cannot represent the value exactly. On
IBM Z (s390x) these instructions currently saturate when overflow
occurs. This means that the round-trip used to detect overflow
succeeds in situations where the conversion is not actually exact.
For example, casting Int32.max to a Float32 via a sitofp instruction
results in Int32.max + 1. This is inexact. However if we then convert
back to an Int32 via a fptosi instruction the result is clamped to
Int32.max and so the round trip has resulted in the same value. We
therefore cannot rely on round trips alone to verify the exactness
of this cast portably.
This commit modifies the conversion routines so that they do not
rely on undefined behavior and avoid using round trips in general.
* Add constraints to FixedWidthInteger.Stride and .Magnitude
Add the constraint that these associatedtypes themselves conform to FixedWidthInteger and to SignedInteger and UnsignedInteger, respectively. These are effectively part of the semantic requirement of the protocol already, because the requirements on .min and .max effectively force FixedWidthInteger to be twos-complement, which requires Magnitude not be Self for signed types. Also, in practice it's generally necessary to have these two constraints in order to effectively use the FixedWidthInteger protocol anyway; witness that by adding them to the protocol, we eliminate them as constraints from a number of extensions.
This also resolves https://bugs.swift.org/browse/SR-8156
Fix Hashable conformance of standard integer types so that the number of bits they feed into hasher is exactly Self.bitWidth.
This was intended to be part of SE-0206. However, it would have introduced additional issues with AnyHashable. The custom AnyHashable representations introduced in the previous commit unify hashing for numeric types, eliminating the problem.
AnyHashable has numerous edge cases where two AnyHashable values compare equal but produce different hashes. This breaks Set and Dictionary invariants and can cause unexpected behavior and/or traps. This change overhauls AnyHashable's implementation to fix these edge cases, hopefully without introducing new issues.
- Fix transitivity of ==. Previously, comparisons involving AnyHashable values with Objective-C provenance were handled specially, breaking Equatable:
let a = (42 as Int as AnyHashable)
let b = (42 as NSNumber as AnyHashable)
let c = (42 as Double as AnyHashable)
a == b // true
b == c // true
a == c // was false(!), now true
let d = ("foo" as AnyHashable)
let e = ("foo" as NSString as AnyHashable)
let f = ("foo" as NSString as NSAttributedStringKey as AnyHashable)
d == e // true
e == f // true
d == f // was false(!), now true
- Fix Hashable conformance for numeric types boxed into AnyHashable:
b == c // true
b.hashValue == c.hashValue // was false(!), now true
Fixing this required adding a custom AnyHashable box for all standard integer and floating point types. The custom box was needed to ensure that two AnyHashables containing the same number compare equal and hash the same way, no matter what their original type was. (This behavior is required to ensure consistency with NSNumber, which has not been preserving types since SE-0170.
- Add custom AnyHashable representations for Arrays, Sets and Dictionaries, so that when they contain numeric types, they hash correctly under the new rules above.
- Remove AnyHashable._usedCustomRepresentation. The provenance of a value should not affect its behavior.
- Allow AnyHashable values to be downcasted into compatible types more often.
- Forward _rawHashValue(seed:) to AnyHashable box. This fixes AnyHashable hashing for types that customize single-shot hashing.
https://bugs.swift.org/browse/SR-7496
rdar://problem/39648819
- Clarify RawValue requirement for OptionSet
- Make Bool counterexample more clearly an error
- Add clarifying note about unsafe arithmetic methods
- Add/refine complexity docs for sequence/collection
- Remove docs from obsoleted symbols
- Standardize on unicode.org for links about Unicode
- More complexity annotations
- Expand dictionary defaulted subscript docs
- Fix error in Dictionary.init(minimumCapacity:) docs
- Improve accuracy of prime number listing
As a general rule, it is safe to mark the implementation of hash(into:) and _rawHashValue(seed:) for @_fixed_layout structs as inlinable.
However, some structs (like String guts, Character, KeyPath-related types) have complicated enough hashing that it seems counterproductive to inline them. Mark these with @effects(releasenone) instead.
This includes various revisions to the APIs landing in Swift 4.2, including:
- Random and other randomness APIs
- Hashable changes
- MemoryLayout.offset(of:)
This is a small performance win; mainly I'm interested in simplifying the code so that there are fewer weird corners for bugs to creep in. Nonetheless, it seems to be about 5% faster with the (fast, dumb) LCG generator.
Custom FixedWidthInteger types may not support this.
Introduce a new (non-public) FixedWidthInteger requirement for generating random values; implement it using &<</+ in the generic case, and specialize it using RandomNumberGenerator._fill(bytes) for the builtin types.
* Use the `__has_include` and `GRND_RANDOM` macros
* Use `getentropy` instead of `getrandom`
* Use `std::min` from the <algorithm> header
* Move `#if` out of the `_stdlib_random` function
* Use `getrandom` with "/dev/urandom" fallback
* Use `#pragma comment` to import "Bcrypt.lib"
* <https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp>
* <https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions>
* Use "/dev/urandom" instead of `SecRandomCopyBytes`
* Use `swift::StaticMutex` for shared "/dev/urandom"
* Add `getrandom_available`; use `O_CLOEXEC` flag
Add platform impl docs
Update copyrights
Fix docs
Add _stdlib_random test
Update _stdlib_random test
Add missing &
Notice about _stdlib_random
Fix docs
Guard on upperBound = 0
Test full range of 8 bit integers
Remove some gyb
Clean up integerRangeTest
Remove FixedWidthInteger constraint
Use arc4random universally
Fix randomElement
Constrain shuffle to RandomAccessCollection
warning instead of error
Move Apple's implementation
Fix failing test on 32 bit systems
* [stdlib] Revise documentation for new random APIs
* [stdlib] Fix constraints on random integer generation
* [test] Isolate failing Random test
* [benchmark] Add benchmarks for new random APIs
Fix Float80 test
Value type generators
random -> randomElement
Fix some docs
One more doc fix
Doc fixes & bool fix
Use computed over explicit
* Remove refs to Countable ranges
* Add `_stdlib_random` for more platforms
* Use `getrandom` (if available) for Android, Cygwin
* Reorder the `_stdlib_random` functions
* Also include <features.h> on Linux
* Add `#error TODO` in `_stdlib_random` for Windows
* Colon after Fatal Error
Performance improvement for Random
gybify ranges
Fix typo in 'basic random numbers'
Add _stdlib_random as a testable method
Switch to generic constraints
Hopefully link against bcrypt
Fix some implementation details
1. Uniform distribution is now uniform
2. Apply Jens' method for uniform floats
Fix a lineable attribute
Initial random api
Use C syscall for I/O
1. Fixed an issue where integers would would result in an infinite loop if they were unsigned, or signed integers always returning negative numbers.
2. Fixed an issue with Bool initialization
Add shuffle functions
Add documentation to Random API
Fix a few typos within the documentation
Fixes more typos
Also states that the range for floating points is from 0 to 1 inclusive
Update API to reflect mailing list discussions
Remove unnecessary import
Make sure not to return upperBound on Range
Use SecRandomCopyBytes on older macOS
Update API to match mailing list discussion, add tests
Added pick(_:) to collection
Added random(in:using:) to Randomizable
Added tests
Fix typo in Randomizable documentation
Rename pick to sampling
Move sampling below random
Update docs
Use new Libc naming
Fix Random.swift with new Libc naming
Remove sampling
gybify signed integer creation
Make FloatingPoint.random exclusive
Refactor {Closed}Range.random
Fix FloatingPoint initialization
Precondition getting a random number from range
Fix some doc typos
Make .random a function
Update API to reflect discussion
Make .random a function
Remove .random() in favor of .random(in:) for all numeric types
Fix compile errors
Clean up _stdlib_random
Cleanup around API
Remove `.random()` requirement from `Collection`
Use generators
Optimize shuffle()
Thread safety for /dev/urandom
Remove {Closed}Range<BinaryFloatingPoint>.random()
Add Collection random requirement
Refactor _stdlib_random
Remove whitespace changes
Clean linux shim
Add shuffle and more tests
Provide finishing tests and suggestions
Remove refs to Countable ranges
Revert to checking if T is > UInt64
Streamline internal String creation. Previously, everything funneled
into a single generic function, however, every single call of the
generic funnel had relevant specific information that could be used
for a more efficient algorithm.
In preparation for efficiently forming small strings, refactor this
logic into a handful of more specialized subroutines to preserve more
specific information from the callers.
The implementation uses DoubleWidth<T> that needs to be removed due to
library binary size issues. Even extracting the single DoubleWidth
method that's used in it would likely result in having to copy a
large portion of the rest of DoubleWidth implementation along with it,
this defeating the purpose.
This change restores the behavior of dividingFullWidth as it was shipped
with Swift 4.1, therefore it's not a breaking change.
* Make the underlying builtins for FP + Vector match Integer.
For stdlib integer types, these are named `_value` and `init(_ _value: Builtin.xxx)`. This patch adopts the same scheme for stdlib floating point and SDK overlay vector types, and removes a legacy init for integers that was only needed to support them. There should be no changes visible outside of the stdlib, and no functional change within the stdlib; the naming of some implementation details is simply more uniform now.
