Inserting and removing a single Unicode.Scalar in a CharacterSet must not
attempt to create a Range<Unicode.Scalar> because the upperBound value might
not always be a valid UnicodeScalar.
This fixes a regression to the fix for SR-2988.
Some cases of using isSuperset can cause crashes, this was caused by improper subclassing callouts; this pr resolves those failures (and provides unit tests for that case)
The cases where the bridge was traversed too much now only causes a single bridge out call (without needing to reallocate or thrash retain/release)
String.components(separatedBy: CharacterSet) should be considerably faster now not only for more apporpriate bridging calls but also no longer needing to bridge arrays back and forth.
Resolves the following issues:
rdar://problem/17281998
rdar://problem/26611771
rdar://problem/29738989
When inserting a closed range/creating a CharacterSet from a closed
range we must not try to convert this range to a half open one by
incrementing the upperBound UnicodeScalar because not all integer values
are valid values for UnicodeScalar
Fixes SR-2988
* Implement CharacterSet.subtracting(_:)
* Add test for CharacterSet.subtract(_:)
* Expand on test for CharacterSet.subtract(_:)
* Address reviewer comment (CharacterSet tests)
* Improve documentation for CharacterSet set algebra
The override methods were not marked with @objc which incorrectly funneled to the abstract base class methods. In the method isSuperset(of:) it would incorrectly hit a requirement of a subclass implementation. This exposed a flaw with NSCharacterSet in which that method cannot recieve subclasses to the other CharacterSet being passed. This is being tracked via rdar://problem/27768939 which will need to be accounted for by CoreFoundation. Until such a time that can be addressed the workaround by using CFCharacterSetIsSupersetOfSet must be used with a copy passed as the other set.
This resolves:
https://bugs.swift.org/browse/SR-2307
All generic bridgeable types can bridge for all their instantiations now. Removing this ferrets out some now-unnecessary traps that check for unbridgeable parameter types.
We were using a precondition which crashes the program when invalid input is
provided. We want to provide a way to gracefully check and handle invalid input
or shutdown the program if necessary.
SR-1930
Foundation provides a number of specific operators defined in the
global scope. Push all of these into their corresponding types. This
cleanup helps verify that the SE-0091 implementation is generally
functional.
We currently specify a few internal ObjC classes. This commit ensures that they can not be accidentally exposed (and thus need to be supported) into the future. Luckily, NSData and NSDictionary/NSMutableDictionary already specify classForCoder in a general way. NSCharacterSet does not.
This commit also establishes unit tests to ensure all three types do not regress from this into the future.
Also, for completeness, it ensures classForArchiver and classForKeyedArchiver return appropriately as well.
Some mutation cases will cause the underlying copy on write cases to crash with a _SwiftNSCharacterSet doesn't respond to -mutableCopyWithZone: failure.
Fixes Bugs:
https://bugs.swift.org/browse/SR-1782
<rdar://problem/26608216>
