Commit Graph

9 Commits

Author SHA1 Message Date
Erik Eckstein
172f3caf85 tests: make tests more resilient to optimizations by passing values to _blackHole
Without `_blackHole`, the optimizer may remove or make assumptions about values, which are not intended by the test.
This fixes the tests when running them in optimize mode and when OSSA modules are enabled.

This is part of rdar://140229560.
2025-01-27 10:38:30 +01:00
Kuba (Brecka) Mracek
663a6fb771 Introduce SWIFT_STDLIB_HAS_TYPE_PRINTING flag to remove the ability to print types at runtime (to save codesize) (#40649) 2021-12-21 17:47:54 -08:00
Karoy Lorentey
666a22feff [test] Modernize hashing throughout the test suite 2018-11-29 17:38:29 +00:00
Doug Gregor
d00a7b75c0 Revert "Update Set<AnyHashable> test case that no longer crashes"
This reverts commit 6abc8489ce.
2018-11-21 07:03:19 -08:00
Doug Gregor
6abc8489ce Update Set<AnyHashable> test case that no longer crashes 2018-10-25 21:43:23 -07:00
Karoy Lorentey
ff91f36a9d [stdlib] Fix AnyHashable's Equatable/Hashable conformance
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
2018-06-25 20:14:01 +01:00
Nate Cook
58933d88c5 [stdlib] Rename index(...) methods to firstIndex(...)
A la SE-204.
2018-04-21 18:07:25 -05:00
Dmitri Gribenko
243a35cd65 Migrate callsites from 'expectEmpty()' to 'expectNil()' 2016-09-10 20:05:42 -07:00
Dmitri Gribenko
ece14ccc2e stdlib: add convenience APIs for Set<AnyHashable> and Dictionary<AnyHashable, *>
Implements SE-0131 "Add AnyHashable to the standard library".
2016-07-26 03:10:52 -07:00