New integer protocols [Not Ready to Merge] #3796

Open
wants to merge 186 commits into
from

Projects

None yet

8 participants

@dabrahams
Member
dabrahams commented Jul 27, 2016 edited

Work on integers from @moiseev

What's in this pull request?

Resolved bug number: (SR-)


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library only for macOS. Simulator standard libraries and
    device standard libraries are not built.
  3. lldb is not built.
  4. The test and validation-test targets are run only for macOS. The optimized
    version of these tests are not run.

A smoke test on Linux does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library incrementally.
  3. lldb is built incrementally.
  4. The swift test and validation-test targets are run. The optimized version of these
    tests are not run.
  5. lldb is tested.

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/private/SwiftPrivate/SwiftPrivate.swift
@@ -13,14 +13,15 @@
import SwiftShims
/// Convert the given numeric value to a hexadecimal string.
-public func asHex<T : Integer>(_ x: T) -> String {
- return "0x" + String(x.toIntMax(), radix: 16)
+public func asHex<T : FixedWidthInteger>(_ x: T) -> String {
@dabrahams
dabrahams Jul 27, 2016 Member

Can’t we convert an arbitrary-width integer to hex?

@moiseev
moiseev Jul 28, 2016 Member

Added a FIXME.

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/SDK/SceneKit/SceneKit.swift
@@ -151,7 +151,7 @@ extension SCNGeometryElement {
/// Creates an instance from `indices` for a `primitiveType`
/// that has a constant number of indices per primitive
/// - Precondition: the `primitiveType` must be `.triangles`, `.triangleStrip`, `.line` or `.point`
- public convenience init<IndexType : Integer>(
+ public convenience init<IndexType : FixedWidthInteger>(
@dabrahams
dabrahams Jul 27, 2016 Member

Why does this require fixed width?

@moiseev
moiseev Jul 28, 2016 Member

It does not require anything. Can as well be BinaryInteger, but I think the underlying implementation will be quite surprised if given something with a random memory representation, i.e. a 3rd party bignum.

@dabrahams
dabrahams Jul 28, 2016 Member

Oh! Heck, their constraint is wrong to begin with. They are assuming all Integers are POD. We should file a radar.

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/CTypes.swift
Builtin.int_memcpy_RawPointer_RawPointer_Int64(
dest, src, size,
- /*alignment:*/ Int32()._value,
+ /*alignment:*/ zero._value,
@dabrahams
dabrahams Jul 27, 2016 Member

I have a feeling we could do away with the constant and just write 0._value here. If that doesn’t work, I’d change the declaration:

let zero: Int32 = 0
@moiseev
moiseev Jul 28, 2016 Member

Using 0._value makes it an Int64. Changing the occurrences to let zero: Int32 = 0.

@dabrahams
dabrahams Jul 28, 2016 Member

Oh, type constraints on the parameters to Builtin.int_memcpy_RawPointer_RawPointer_Int64 don’t handle the deduction? That’s weird. It’s not like any Builtin is overloaded.

@dabrahams dabrahams commented on an outdated diff Jul 27, 2016
stdlib/public/core/FloatingPoint.swift.gyb
@@ -834,12 +829,16 @@ extension FloatingPoint {
}
%end
+// FIXME(integers): maybe uncomment it back
@dabrahams
dabrahams Jul 27, 2016 Member

Why bring this back? If there’s a possible reason, the FIXME should note it

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/IntegerParsing.swift.gyb
@@ -30,9 +27,9 @@ UIntMax = 'UInt%s' % int_max_bits
///
/// - Note: If `text` begins with `"+"` or `"-"`, even if the rest of
/// the characters are `"0"`, the result is `nil`.
-internal func _parseUnsignedAsciiAsUIntMax(
- _ u16: String.UTF16View, _ radix: Int, _ maximum: UIntMax
-) -> UIntMax? {
+internal func _parseUnsignedAsciiAsUInt64(
@dabrahams
dabrahams Jul 27, 2016 Member

Seems to me that we want these all to be generic over every BinaryInteger type, neh?

@moiseev
moiseev Jul 28, 2016 edited Member

Yes. But changes like this are better done when the whole thing at least compiles.

@dabrahams
dabrahams Jul 28, 2016 Member

Then you need to leave a FIXME in place, right?

@moiseev
moiseev Jul 28, 2016 Member

Added a few here.

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
@@ -14,6 +14,8 @@
# Utility code for later in this template
#
+from SwiftIntTypes import all_integer_types, int_max_bits, should_define_truncating_bit_pattern_init
@dabrahams
dabrahams Jul 27, 2016 Member

Are we keeping the truncating: init? Since we have truncatingOrExtending: it seems slightly unnecessary. Though it could help expressivity...

@moiseev
moiseev Jul 28, 2016 Member

There is a FIXME elsewhere to consider merging them.

@dabrahams
Member

Lots of missing doc comments in the code!

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
public func signum() -> Self {
- // FIXME(integers): implement
- fatalError()
+ if self < (0 as Self) { return -1 }
@dabrahams
dabrahams Jul 27, 2016 Member

if these as Selfs are really needed I think there’s a compiler bug that should be reported. Otherwise we should just say 0.

@moiseev
moiseev Jul 28, 2016 Member

They were needed at some point, but are not now. Removed.

@dabrahams dabrahams commented on an outdated diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
public func < <T : BinaryInteger>(lhs: T, rhs: T) -> Bool {
return lhs.isLess(than: rhs)
}
+// FIXME(integers): these seem to be important for Int-backed enums
@dabrahams
dabrahams Jul 27, 2016 Member

important in what way?

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
@@ -283,8 +340,8 @@ public func != <T : BinaryInteger, U : BinaryInteger>(lhs:T, rhs: U) -> Bool {
@_transparent
public func < <T : BinaryInteger, U : BinaryInteger>(lhs: T, rhs: U) -> Bool {
- let lhsSign = lhs < 0 ? -1 : lhs > 0 ? 1 : 0
- let rhsSign = rhs < 0 ? -1 : rhs > 0 ? 1 : 0
+ let lhsSign = lhs < (0 as T) ? -1 : lhs > (0 as T) ? 1 : 0
+ let rhsSign = rhs < (0 as U) ? -1 : rhs > (0 as U) ? 1 : 0
@dabrahams
dabrahams Jul 27, 2016 Member

If these are ambiguous without the casts, we should make it a requirement of BinaryInteger that there be a (Self,Self) version of the comparison.

@moiseev
moiseev Jul 28, 2016 Member

These are not ambiguous, it's the inlining. It is trying to inline itself. Type cast makes it call the non-generic version, and avoid the problem.
We already have a (Self, Self) comparison requirement on the BinaryInteger, it's just called isLess(than:). Given SE-0091 it will become a static func < (Self, Self) -> Bool.
For now, changing explicit type cast to using isLess(than:).

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
@@ -423,17 +480,17 @@ public func ${x.operator}= <T: FixedWidthInteger>(lhs: inout T, rhs: T) {
% for x in maskingShifts:
-@_transparent
+//@_transparent
@dabrahams
dabrahams Jul 27, 2016 Member

Why are these commented out?

@moiseev
moiseev Jul 28, 2016 edited Member

There was an inlining loop that I decided to avoid first and fix later.

@dabrahams dabrahams commented on an outdated diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
/// occurs, the behavior is undefined.
///
/// Note: use this function to avoid the cost of overflow checking
/// when you are sure that the operation won't overflow.
@_transparent
- public func unsafe${capitalize(x.name)}(rhs: Self) -> Self {
- let (result, overflow) = self.${x.name}WithOverflow(${callLabel}rhs)
+ public func unsafe${capitalize(x.name)}(other: Self) -> Self {
@dabrahams
dabrahams Jul 27, 2016 Member

This should be a label-less argument, shouldn’t it?

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
public func ${x.nonMaskingOperator} <
T: FixedWidthInteger
>(lhs: T, rhs: Int) -> T {
- // FIXME(integers): uncomment once Int conforms to BinaryInteger
- fatalError()
- //let overshiftR = T.isSigned ? lhs &>> (T.bitWidth - 1) : 0
- //let overshiftL: T = 0
- //if _fastPath(rhs >= 0) {
- //if _fastPath(rhs < T.bitWidth) {
- //return lhs.${x.name}(T(extendingOrTruncating: rhs))
- //}
- //return overshift${'LR'['R' in x.name]}
- //}
-
- //if _slowPath(rhs <= -T.bitWidth) {
- //return overshift${'RL'['R' in x.name]}
- //}
- //return lhs ${x.operator.translate(maketrans('<>', '><'))} -rhs
@dabrahams
dabrahams Jul 27, 2016 Member

It’s not exactly clear to me what the basis for this comparison is, or how to evaluate the changes. Could you clarify?

@moiseev
moiseev Jul 28, 2016 Member

The implementation is copied verbatim from the integers prototype, the last known state of which is available here.

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
- //repeat {
- //let r = x % 10
- //x /= 10
- //buf.append(
- //UnicodeScalar(
- //ascii0 + Int(Word(extendingOrTruncating: r)._storage)))
- //}
- //while x != 0
- //return String(buf.reversed().lazy.map { Character($0) })
+ var x = self
+ repeat {
+ let r = x % 10
+ x /= 10
+ buf.append(
+ UnicodeScalar(
+ ascii0 + Int(UInt(extendingOrTruncating: r)._value))!)
@dabrahams
dabrahams Jul 27, 2016 Member

This looks too complicated; there ought to be a simpler way to express whatever the intention is, I think.

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
@_transparent
public init<T : BinaryInteger>(_ source: T) {
// FIXME(integers): uncomment checks
- //_assertCond(
- //source >= 0, "negative value \(source) not representable by \(Self.self)")
+ //_precondition(source >= 0,
@dabrahams
dabrahams Jul 27, 2016 Member

The old checks provide better user experience and I think _assertCond might be something the performance team can optimize better. We should check with them before making the change to _precondition.

@moiseev
moiseev Jul 28, 2016 Member

Optimizer team explicitly advised against _assertCond. We can it leave it to them to replace with something more appropriate though...

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/Integers.swift.gyb
+@_transparent
+public func ${op} (lhs: ${Self}, rhs: ${Self}) -> ${Self} {
+ return lhs.${method}(${label}rhs)
+}
+% end
+//===--- end of FIXME(integers) -------------------------------------------===//
+
+% end # end of concrete FixedWidthInteger section
+
+
+// FIXME(integers): inline manually everywhere
+public func numericCast<T : BinaryInteger, U : BinaryInteger>(_ x: T) -> U {
+ return U(x)
+}
+
+internal func _unsafePlus(_ lhs: Int, _ rhs: Int) -> Int {
@dabrahams
dabrahams Jul 27, 2016 Member

what are these for?

@moiseev
moiseev Jul 28, 2016 Member

They are used elsewhere, and I just copied them from the old implementation to make the whole thing compile. The plan is to replace them with the method call, since we have the unsafeOP methods on FixedWidthInteger.

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/Slice.swift.gyb
@@ -395,7 +395,7 @@ public struct ${Self}<Base : ${BaseRequirements}>
} else {
let shouldUpdateStartIndex = bounds.lowerBound == _startIndex
let lastValidIndex = _base.index(before: bounds.lowerBound)
- let newEndIndexOffset =
+ let newEndIndexOffset: Base.IndexDistance =
@dabrahams
dabrahams Jul 27, 2016 Member

Why isn’t this type deduced?

@dabrahams dabrahams commented on an outdated diff Jul 27, 2016
stdlib/public/core/Sort.swift.gyb
@@ -140,7 +140,7 @@ func _introSort<C>(
var areIncreasingVar = areInIncreasingOrder
% end
let count =
- elements.distance(from: range.lowerBound, to: range.upperBound).toIntMax()
+ elements.distance(from: range.lowerBound, to: range.upperBound)
@dabrahams
dabrahams Jul 27, 2016 Member

Maybe just drop the named constant now that we can do the comparison without type coercion.

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/StaticString.swift
@@ -160,7 +160,9 @@ public struct StaticString
// unrelated buffer is not accessed or freed.
self._startPtrOrData = Builtin.ptrtoint_Word(_start)
self._utf8CodeUnitCount = utf8CodeUnitCount
- self._flags = Bool(isASCII) ? (0x2 as UInt8)._value : (0x0 as UInt8)._value
+ self._flags = Bool(isASCII)
+ ? (0x2 as UInt8)._value
+ : (0x0 as UInt8)._value
@dabrahams
dabrahams Jul 27, 2016 Member

Can we do

self._flags = isASCII ? 0x2._value : 0x0._value

?

@dabrahams dabrahams and 1 other commented on an outdated diff Jul 27, 2016
stdlib/public/core/StringLegacy.swift
@@ -238,8 +238,8 @@ extension String {
/// let max = String(Int.max)
/// print("\(max) has \(max.utf16.count) digits.")
/// // Prints "9223372036854775807 has 19 digits."
- public init<T : _SignedInteger>(_ v: T) {
- self = _int64ToString(v.toIntMax())
+ public init<T : FixedWidthInteger>(_ v: T) {
+ self = _int64ToString(Int64(v))
@dabrahams
dabrahams Jul 27, 2016 Member

This looks wrong; the constraint should be more general, and it should work if the value is wider than 64 bits.

@moiseev
moiseev Jul 28, 2016 Member

Yes. But should it be part of this change? 64 bits is maximum we have so far, so I figured it was sufficient this way. At least for now, given time constraints.

@dabrahams dabrahams commented on the diff Jul 27, 2016
stdlib/public/core/StringLegacy.swift
_ value: T, radix: Int, uppercase: Bool = false
) {
_precondition(radix > 1, "Radix must be greater than 1")
self = _int64ToString(
- value.toIntMax(), radix: Int64(radix), uppercase: uppercase)
+ Int64(value), radix: Int64(radix), uppercase: uppercase)
@dabrahams
dabrahams Jul 27, 2016 Member

Also looks wrong for the same reasons.

@dabrahams dabrahams commented on an outdated diff Jul 27, 2016
stdlib/public/core/Unicode.swift
@@ -344,7 +344,7 @@ public struct UTF8 : UnicodeCodec {
return (nil, 3)
}
// Extract data bits.
- // FIXME(integers): remove extra type casts
+ // FIXME(integers): remove extra type hints
@dabrahams
dabrahams Jul 27, 2016 Member

I think we can use masking shifts here, too?

@dabrahams dabrahams commented on an outdated diff Jul 27, 2016
stdlib/public/core/UnsafeRawPointer.swift.gyb
@@ -410,7 +410,7 @@ public struct Unsafe${Mutable}RawPointer : Strideable, Hashable, _Pointer {
// FIXME: to be replaced by _memcpy when conversions are implemented.
Builtin.int_memcpy_RawPointer_RawPointer_Int64(
(self + offset)._rawValue, rawSrc, UInt64(sizeof(T.self))._value,
- /*alignment:*/ Int32(0)._value,
+ /*alignment:*/ Int32()._value,
@dabrahams
dabrahams Jul 27, 2016 Member

Does 0._value work?

@jessesquires jessesquires referenced this pull request in SwiftWeekly/swiftweekly.github.io Jul 28, 2016
Closed

Issue 33 - after Swift 3 #57

moiseev added some commits Jul 18, 2016
@moiseev @moiseev moiseev Concrete underscored types with fatalErrors everywhere 7b9baa0
@moiseev @moiseev moiseev Using gybbed all_integer_types c3967d8
@moiseev @moiseev moiseev uncommenting failing exact initializer from BinaryInteger in Arithmetic 3ed8fda
@moiseev @moiseev moiseev un-underscoring 1ed25bd
@moiseev @moiseev moiseev WIP eliminating compilation errors one by one... 1867ca4
@moiseev @moiseev moiseev Operators compile 28a252e
@moiseev @moiseev moiseev infinite inlining loop 4595052
@moiseev moiseev SetAlgebra conformance errors 6ccc6ae
@moiseev moiseev uncommenting some implementations f3b472c
@moiseev moiseev core and overlays build e2e032b
@moiseev moiseev IT BUILDS b771fa0
@moiseev moiseev toIntMax is gone 6dbb572
@moiseev moiseev no IntMax in IntegerParsing ac7201d
@moiseev moiseev Addressing some of the FIXMEs 1dd6c2d
@moiseev moiseev adding a proper arguemnt label to 'unsafe' methods 0195fb1
@moiseev moiseev replacing Int32()._value with let zero: Int32 = 0 4cc7c00
@moiseev moiseev removing commented out default implementation 2df96d0
@moiseev moiseev FIXMEs to change FixedWidthInteger to BinaryInteger in generic code 655bfe2
@moiseev moiseev removing explicit typecasts 8341f6c
@moiseev moiseev FIXME for the unsafe functions 1f07b84
@moiseev moiseev a better fixme message on == (Int, Int). removing < (Int, Int) 148282d
@moiseev moiseev removing IntegerArithmetic.swift d42743f
@moiseev moiseev implementing popcount 3517b62
@moiseev moiseev removing unnecessary fatalError calls bf1467c
@moiseev moiseev a bunch of unavailable declarations 522ad4e
@moiseev moiseev fixing the benchmarks 1cb48c4
@moiseev moiseev Turning operators into static funcs 969bbfb
@moiseev moiseev Simplifying too complex expressions in benchmarks with type casts f01bc2d
@moiseev moiseev getting rid of toIntMax in StdlibCollectionUnittest 2540b6d
@dabrahams

Shouldn't at least some of these have renamed: clauses?

Member

They are not the exact equivalents...

Member

I know. Dmitri and I think we should at least help users get close.

Dave Abrahams added some commits Jul 30, 2016
Dave Abrahams Merge 'origin/master' into new-integer-protocols f06a9a1
Dave Abrahams [stdlib] Correct renamed protocol @available decls 59adfe9
Dave Abrahams [emacs support] properly parse some test failures 0d1477a
Dave Abrahams [stdlib] Improve unavailable diagnostics
Making these generic and removing inout from the arguments cuts down on
the number of useless notes we give users when they try to use them.
Arguably the compiler should do better, but this moves our test results
along.
ccf555c
Dave Abrahams [stdlib] Fix constraint tests for new integers d4030a9
Dave Abrahams [stdlib] New integers simplify generic code! 60160cf
Dave Abrahams Provisionally adjust DebugInfo test 4af655e
@dabrahams
Member

@adrian-prantl please review this to make sure it's the right fix. Codegen is injecting an alloc_stack after the entry: label

Member

Thanks! I think the CHECK-NEXT is here to ensure that we are still in the same function.
replacing the
CHECK: entry:
with a
CHECK-NOT: {{ ret }}
would probably be even better but this is fine, too.

@karwa
Contributor
karwa commented Aug 4, 2016

Just to check: this is definitely going to make Swift 3.0, right?

@gribozavr
Collaborator

Just to check: this is definitely going to make Swift 3.0, right?

Right now it looks like it will not. There are many test failures that haven't been solved, we noticed performance issues, and the implementation work is not even complete.

natecook1000 and others added some commits Aug 19, 2016
@natecook1000 @moiseev natecook1000 [Integer protocols] Make .negate() the customization point (#4413)
The SignedArithmetic protocol provides default implementations for both
negate() and negated(), with negate() calling negated(). This is inconsistent
with the Arithmetic protocol, which provides implementations of the nonmutating
methods that call their mutating counterparts. This flips the implementations
of negate() and negated() so an implementer only has to focus on mutating
methods.
d6dec00
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols ea8e0f0
@moiseev moiseev [integers] making stdlib compile after merging master 06dfb51
@moiseev moiseev [integers] adding labels to the quotientAndRemainder return tuple f6a7343
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 84f3ccd
@moiseev moiseev Merge branch 'master' into new-integer-protocols 6803cda
@moiseev moiseev turning the memcpy and memmove alignment arguments into compile time …
…constants
09c3e80
@moiseev moiseev Merge branch 'master' into new-integer-protocols 61ba07f
@moiseev moiseev Adding a (bad) implementation of init(_ source: FloatingPoint) to fix…
… some tests
3a43d8c
@moiseev moiseev introducing concrete initializers from all floating point types e0b8532
@moiseev moiseev Merge branch 'master' into new-integer-protocols 17b3e38
@natecook1000 @moiseev natecook1000 [stdlib] Revise documentation for integer types & protocols (#5083)
* [stdlib] Revise documentation for integer types & protocols

* Update with feedback

* [stdlib] Additional integer documentation revisions
68a307e
@moiseev moiseev Merge branch 'new-integer-protocols' of github.com:apple/swift into n…
…ew-integer-protocols
530e97e
@moiseev moiseev [WIP] fixing some of the integer related test failures 08cf1de
@moiseev moiseev Merge branch 'master' into new-integer-protocols 99837a4
@moiseev moiseev Operators as static funcs for Arithmetic (see SE-0091) 5cc2c8c
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 9428c82
@moiseev moiseev Moving unavailable operators out of concrete types 9cba734
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 4902db2
@moiseev moiseev Adding specific versions of arithmetics operators for CGFloat to spee…
…d up compilation
c91dce7
@moiseev moiseev Revert "Adding specific versions of arithmetics operators for CGFloat…
… to speed up compilation"

This reverts commit c91dce7.
9a0f3ba
@moiseev moiseev Breaking up complex expression to improve compilation time 2190819
@moiseev moiseev Cleaning up the gyb 079ead9
@moiseev moiseev Removing FIXMEs fe3c737
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 8d1155c
@moiseev moiseev Merge branch 'master' into new-integer-protocols b2fecd2
@moiseev moiseev Comparable operators to static funcs 543fd10
@moiseev moiseev Choosing the right overloads for comparison operators a9af3d6
@moiseev moiseev Minor fixes and improvements e3a2e5b
@moiseev moiseev Avoiding the force unwrap in UnsafePointer.count 196ea95
@moiseev moiseev Turning more operators into static funcs 47ba2e9
@moiseev moiseev Get rid of _DisallowMixedSignArithmetic 3dcdd1a
@moiseev moiseev Merge branch 'master' into new-integer-protocols 8912dc0
@moiseev moiseev Adding back accidentally deleted UnsignedInteger protocol 01ec747
@moiseev moiseev Using Strideable APIs instead of + and - 8e109de
@moiseev moiseev Different Strideable conformances for Swift 3 and Swift 4 62044de
@benrimmington benrimmington referenced this pull request in apple/swift-evolution Nov 13, 2016
Merged

[Status] Add section for “Implementation in progress” #558

@dabrahams

It would be nice to avoid expanding the overload set like this if possible

Member

This is something that optimizer would be able to do (and there is a FIXME for that). We discussed it with @swiftix and he said it's not unreasonable.

@dabrahams

Maybe we should create an identity overload for numericCast and make it deprecated, so we catch unneeded uses?

Member

I think optimizer will figure it out, if performance is in question. But from the code quality perspective, it's not a bad idea at all. I'll add it.
This one I caught only because it became ambiguous due to the new <= (T, Int).

@moiseev
Member
moiseev commented Nov 20, 2016

@swift-ci Please benchmark

@moiseev moiseev self-assigned this Nov 20, 2016
@swift-ci
Contributor

Build comment file:

Build failed before running benchmark.


moiseev added some commits Nov 28, 2016
@moiseev moiseev adding type hints in signum implementation 164232d
@moiseev moiseev Merge branch 'master' into new-integer-protocols 70b2343
@moiseev moiseev Removing unary + for floating point types and changing the unary - to…
… a static method

Addresses: <rdar://problem/16424438>
3aba0f7
@moiseev moiseev Fixing the benchmark crash
... by removing the + - overloads for Strideable, and only leaving them
for pointers (both Strideable and _Pointer).

Strideable was used in the past to simplify advancing collection
indices, but with new collection indexing model it is no longer
necessary to overload `+` and `-` for all strideable types..
2b50c6f
@moiseev moiseev Changing == and < on UnsafeRawPointer to static funcs d2d814e
@moiseev moiseev Fixing the benchmarks now that the + is not defined for Strideable 3b4c804
@moiseev moiseev Merge branch 'master' into new-integer-protocols 3059b3c
@moiseev moiseev Making StdlibUnittest compile in absense of + on Strideable 7afd9bb
@moiseev moiseev Not using arithmetic operators on strideables in test fa8adad
@moiseev moiseev Deprecating the BitwiseOperations protocol in favor of FixedWidthInteger baf392e
@moiseev moiseev Adding trailingZeros property to BinaryInteger protocol
<rdar://problem/17505796>
d8e35f2
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 356c15c
@moiseev moiseev Deprecation message to FixedWidthInteger.allZeros b9c910a
@moiseev moiseev Consistent implementation of mutating vs non-mutating operators on Fi…
…xedWidthInteger
ae89d38
@moiseev moiseev Adding prefix ~ protocol requirement to FixedWidthInteger edc08ac
@moiseev moiseev Type hints for operators 01ba85d
@moiseev moiseev More type hints and inlining to speed up integer convertions 485e7c0
@moiseev moiseev Merge branch 'master' into new-integer-protocols 9b2f885
@moiseev moiseev Speeding up conversion between integer types
This change levereges the fact that there is no need to check for the
upper bound if the source type if narrower than the destination type.
4831aac
@moiseev moiseev Speeding up .description for built-in integers 72fe1e4
@moiseev moiseev Merge branch 'master' into new-integer-protocols 5fb929c
@moiseev moiseev Speeding up the heterogeneous == and < by using more opimizable checks 74253ea
@moiseev moiseev Cleaning up the smart shifts c655d8a
@moiseev moiseev Commenting an overload that leads to compiler error b42c514
@moiseev moiseev Removing overloads of == on concrete types in favor of a generic one …
…that is now faster
0b271e8
@moiseev moiseev Merge branch 'master' into new-integer-protocols bfbab79
@moiseev moiseev Fixing a typo 7a8a840
@moiseev moiseev Speeding up the generic smart shift 26111e8
@moiseev moiseev Revert "Speeding up the generic smart shift"
This reverts commit 26111e8.
701740a
@moiseev moiseev Adding integer unit tests from the original prototype 265060d
@moiseev moiseev Merge branch 'master' into new-integer-protocols 9a8cdbc
@moiseev moiseev Adding some doubleWidthMultiply and bouldWidthDivide tests 94564eb
@moiseev moiseev Using init(extendingOrTruncating:) instead of a deprecated init(trunc…
…atingBitPattern:)
61b923f
@moiseev moiseev Using masking shifts d7e92a5
@moiseev moiseev Removing dead and commented code 9518082
@moiseev moiseev Type hints in comparisons d318ec5
@moiseev moiseev Overflow checks in division/modulo operators + tests ea8f220
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 3b7dd4a
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 3276aa5
@moiseev moiseev doubleWidth operations on Int64 need special implementation for 32bit…
… platforms
059f7a5
@moiseev moiseev Moving bitwise operations and shifts to BinaryInteger protocol 4c1cc0f
@moiseev moiseev Implementing non-mutating shifts using mutating ones (for consistency) 4675e12
@moiseev moiseev Adding smart shift default implementations to BinaryInteger via an ex…
…tension
51128d3
@moiseev moiseev Getting rid of no longer needed minimumSignedRepresentationBitWidth 138d9df
@moiseev moiseev Adding endianness related inits and properties to FixedWidthInteger d9013a4
@moiseev moiseev Introducing abs<T : SignedArithmetic & Comparable> 36ad3b4
@moiseev moiseev Adding DoubleWidth<> 156b171
@moiseev moiseev Correcting doubleWidthDivide precondition e91536b
@moiseev moiseev Adding init(bitPattern: FLOATING_POINT) to Int32 and Int64 9968995
@moiseev moiseev Using trailingZeros and leadingZeros provided by integers in floating…
… point types
d356e14
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols 27889c6
@moiseev moiseev Fixing some and XFAILing other failing tests 6a06b66
@moiseev moiseev Fixing stdlib tests d71c73b
@moiseev moiseev More test fixes e1de9fc
@moiseev moiseev Disabling some SILGen tests, that started to fail due to new integers 7ecd605
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols aecccc7
@moiseev moiseev Fixing and XFAILing tests a872ada
@moiseev moiseev Fixing couple more tests ed50ac9
@moiseev moiseev Merge remote-tracking branch 'origin/master' into new-integer-protocols fa7368a
@moiseev moiseev Making non-masking shift helper function public (compiler requires it…
… now)
e1a8e28
@moiseev moiseev Removing explicit implementation of arithmetic operators from Decimal…
… in favor of defaults
d5e56d6
@moiseev moiseev Fixing more tests a167238
@moiseev moiseev Getting rid of Arithmetic.init() in favor of 0 de5b03d
@dabrahams

I don't think this comment is right. Seems to me we just know they have the same sign.

Member

Ouch. It is very wrong.

Member

Does that make the code wrong too?

@dabrahams

If one is unsigned, they're both unsigned, no?

Member

I don't see why/

Member

I was wrong, nevermind!

@dabrahams

@natecook1000 I think the bitWidth is totally irrelevant to trailingZeros, innit?

Contributor

Totally and completely! I can reword that.

@dabrahams

I think > should be >=; why aren't our tests catching that? Am I mistaken?

Member

It should. According to LLVM reference, the result of shift operations is undefined for the shift amount >= to the bit width of the value being shifted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment