SE 0184a implementation #12200

tayloraswift · 2017-09-30T19:51:35Z

Implementation of SE 0184a (Unsafe[Mutable][Raw][Buffer]Pointer overhaul, part 1).

xwu

This is awesome; so glad that you're pushing ahead with this change! Just two minor comments on the documentation, and some formatting nits.

xwu · 2017-09-30T22:21:05Z

stdlib/public/core/StringCore.swift

-        (tailStart + (growth &<< elementShift)).copyBytes(
-          from: tailStart, count: tailCount &<< elementShift)
+        (tailStart + (growth &<< elementShift)).copyMemory(
+        from: tailStart, byteCount: tailCount &<< elementShift)


Nit: could you please restore the indentation here?

xwu · 2017-09-30T22:25:33Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  /// Deallocates the heap block previously allocated at this buffer pointer’s 
+  /// base address. 
+  ///
+  /// This buffer pointer’s `baseAddress` must be `nil` or a pointer to a previously 


These are nicely documented!

Small nit here and elsewhere below: could you please straighten the apostrophe? I believe it interferes with some downstream tooling and have seen others go through and do this sort of clean-up; might as well have it straightened in the first place.

xwu · 2017-09-30T22:26:51Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  /// pointer.
+  /// 
+  /// When you allocate memory, always remember to deallocate once you're
+  /// finished.


It's certainly important, but could we choose only one of the two sentences above? They say exactly the same thing.

this duplication also already exists in UnsafeMutablePointer

xwu · 2017-09-30T22:29:22Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  /// to be the same size as its `Pointee` type.
+  @_inlineable
+  public func withMemoryRebound<T, Result>(
+    to type: T.Type, _ body: (${Self}<T>) throws -> Result) rethrows -> Result {


Formatting nit: typically, in stdlib style, when the parameters start on another line, the closing parenthesis is also on a separate line like so:

@_inlineable public func withMemoryRebound<T, Result>( to type: T.Type, _ body: (${Self}<T>) throws -> Result ) rethrows -> Result { // ... }

xwu · 2017-09-30T22:31:22Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+        Builtin.bindMemory(base._rawValue, count._builtinWordValue, Element.self)
+      }
+
+      return try body(${Self}<T>( start: Unsafe${Mutable}Pointer<T>(base._rawValue),


Nit: extra space after opening parenthesis, although stdlib formatting would actually call for the following:

return try body(${Self}<T>( start: Unsafe${Mutable}Pointer<T>(base._rawValue), count: capacity))

xwu · 2017-09-30T22:40:21Z

stdlib/public/core/UnsafeRawPointer.swift.gyb

-  public func initializeMemory<T>(as type: T.Type, at index: Int = 0,
-    count: Int = 1, to value: T
+  public func initializeMemory<T>( 
+    as type: T.Type, repeating repeatedValue:T, count: Int


Nit: space after repeatedValue:; remove space at the end of the previous line.

xwu · 2017-09-30T22:41:13Z

test/stdlib/UnsafeRawPointer.swift

-  (rawPtr + MemoryLayout<Int>.stride).copyBytes(
-    from: roPtr, count: 2 * MemoryLayout<Int>.stride)
+  (rawPtr + MemoryLayout<Int>.stride).copyMemory(
+  from: roPtr, byteCount: 2 * MemoryLayout<Int>.stride)


Nit: please restore indent.

xwu · 2017-09-30T22:41:20Z

test/stdlib/UnsafeRawPointer.swift

-  rawPtr.copyBytes(
-    from: roPtr + MemoryLayout<Int>.stride, count: 2 * MemoryLayout<Int>.stride)
+  rawPtr.copyMemory(
+  from: roPtr + MemoryLayout<Int>.stride, byteCount: 2 * MemoryLayout<Int>.stride)


Nit: please restore indent.

xwu · 2017-09-30T22:41:28Z

test/stdlib/UnsafeRawPointer.swift

-  rawPtr.copyBytes(
-    from: roPtr + 2 * MemoryLayout<Int>.stride, count: 2 * MemoryLayout<Int>.stride)
+  rawPtr.copyMemory(
+  from: roPtr + 2 * MemoryLayout<Int>.stride, byteCount: 2 * MemoryLayout<Int>.stride)


Nit: please restore indent.

xwu · 2017-09-30T22:41:38Z

test/stdlib/UnsafeRawPointer.swift

-  (rawPtr + 2 * MemoryLayout<Int>.stride).copyBytes(
-    from: roPtr, count: 2 * MemoryLayout<Int>.stride)
+  (rawPtr + 2 * MemoryLayout<Int>.stride).copyMemory(
+  from: roPtr, byteCount: 2 * MemoryLayout<Int>.stride)


Nit: please restore indent.

tayloraswift · 2017-10-01T00:38:35Z

@xwu better?

gottesmm · 2017-10-01T17:54:41Z

@Kelvin13 Please rebase instead of merging in on feature branches. I am going to kick off a run and put a [WIP] don't merge in the title.

gottesmm · 2017-10-01T17:55:07Z

@swift-ci test

swift-ci · 2017-10-01T17:57:05Z

Build failed
Swift Test Linux Platform
Git Sha - 6c14eec80f3d4db0462c7c915cd06e6231a3d9f8

swift-ci · 2017-10-01T17:59:09Z

Build failed
Swift Test OS X Platform
Git Sha - 6c14eec80f3d4db0462c7c915cd06e6231a3d9f8

tayloraswift · 2017-10-02T03:14:56Z

@swift-ci test

moiseev · 2017-10-02T18:08:41Z

Since we're removing sil-serialize-all mode for the standard library at the moment, please mark all the new @_inlineable attributes that you're not sure about with a FIXME(sil-serialize-all): to be reviewed later.

moiseev · 2017-10-02T18:14:03Z

/cc @natecook1000 for the documentation changes.

moiseev · 2017-10-02T18:17:30Z

I simply wholesale applied `@_inlineable` everywhere, without giving it much thought. A `sil-serialize-all` marker will allow us to review usages of it later.

…

On Sep 30, 2017, at 4:39 PM, Xiaodi Wu ***@***.***> wrote: @xwu commented on this pull request. In stdlib/public/core/UnsafeRawBufferPointer.swift.gyb <#12200 (comment)>: > + /// + /// Use the `bindMemory(to:)` method to bind the memory referenced + /// by this buffer to the type `T`. The memory must be uninitialized or + /// initialized to a type that is layout compatible with `T`. If the memory + /// is uninitialized, it is still uninitialized after being bound to `T`. + /// + /// - Warning: A memory location may only be bound to one type at a time. The + /// behavior of accessing memory as a type unrelated to its bound type is + /// undefined. + /// + /// - Parameters: + /// - type: The type `T` to bind the memory to. + /// - Returns: A typed buffer of the newly bound memory. The memory in this + /// region is bound to `T`, but has not been modified in any other way. + /// The typed buffer references `self.count / MemoryLayout<T>.stride` instances of `T`. + @_transparent I noticed there were a few places where Max used both annotations in that other PR, which is why I’m wondering if it’s necessary here. I was of the same understanding as you, but now I’m not so sure. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12200 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD6CyQ02jwne2Iy20BKqAFPa5rIj6Bbks5sntE9gaJpZM4PprCc>.

jckarter · 2017-10-02T20:47:24Z

@swift-ci Please test

jckarter · 2017-10-02T21:55:00Z

@swift-ci Please test

swift-ci · 2017-10-02T22:00:30Z

Build failed
Swift Test Linux Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

swift-ci · 2017-10-02T22:46:51Z

Build failed
Swift Test OS X Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

jckarter · 2017-10-02T23:06:46Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please test

swift-ci · 2017-10-02T23:17:38Z

Build failed
Swift Test Linux Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

jckarter · 2017-10-03T00:40:58Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please clean test

swift-ci · 2017-10-03T01:19:53Z

Build failed
Swift Test Linux Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

swift-ci · 2017-10-03T02:45:49Z

Build failed
Swift Test OS X Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

natecook1000

Looking great! Just a few notes inline.

natecook1000 · 2017-10-03T14:38:22Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  ///
+  /// Warning: Unlike this method, the destination type `T` of 
+  /// `Unsafe${Mutable}Pointer.withMemoryRebound(to:capacity:_:)` requires `T` 
+  /// to be the same size as its `Pointee` type.


This warning doesn't need to be here.

yes it does. it has to do with how the type gets rebound by the builtins.

I don't think we don't need a warning about the usage of an UnsafePointer method here in the documentation for an UnsafeBufferPointer method. The documentation for UnsafePointer.withMemoryRebound already covers this precondition, and it isn't relevant here. (If this is meant to be a code comment, then it's fine, but it should double-slashed and in the method body.)

Maybe an even better option would be to relax the precondition in UnsafePointer.withMemoryRebound so that the two similar methods have the same semantics. cc @atrick

The buffer version of withMemoryRebound has an additional constraint. MemoryLayout<T>.stride == MemoryLayout<Element>.stride. This is necessary because the user doesn't provide a count for the resulting number of T elements. This buffer API simply doesn't make sense without this precondition.

I think the warning reads wrong. It sounds the precondition is on the UnsafePointer API, but that's wrong.

i don’t really care about this use case enough to hold up the proposal over it, but what if you want to fuse a buffer of UInt8s into UInt32s or something?

let integers:[UInt32] = bytes.withMemoryRebound(to: UInt32.self) { return $0.map(UInt32.init(bigEndian:)) }

My PNG library does this a lot but with raw buffer pointers as a workaround. js. if you still disagree i’ll just take it out. It’ll save us an integer division at least

That's a great use case for raw buffers!

Well, your implementation is memory safe for trivial values... However, even if we came up with a set of rules that allowed withMemoryRebound to reinterpret memory as differently sized integers (which is probably not a good idea), then in practice the integer division alone is a serious sticking point here.

You’re probably right tbh. Using raw buffers is a bit more awkward for things like matrix buffers where you have a bunch of matrices stored back to back as an array of Floats. But that’s really a job for fixed sized arrays, not buffer pointer rebinds.

someone run the ci pls

@atrick you have to do it twice because of the sha

natecook1000 · 2017-10-03T15:01:12Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

@@ -366,6 +389,140 @@ public struct Unsafe${Mutable}BufferPointer<Element>
  public func makeIterator() -> UnsafeBufferPointerIterator<Element> {
    return UnsafeBufferPointerIterator(_position: _position, _end: _end)
  }
+
+  /// Deallocates the heap block previously allocated at this buffer pointer’s 
+  /// base address. 


I don't think we're using "heap block" anywhere else in these docs. Can you use "memory region" or "memory block" instead?

natecook1000 · 2017-10-03T15:04:02Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  /// allocated memory block. If `baseAddress` is `nil`, this function does nothing.
+  /// Otherwise, the memory must not be initialized or `Pointee` must be a trivial 
+  /// type. This buffer pointer's `count` must be equal to the allocated 
+  /// size of the heap block.


Can we make it clear that you only use deallocate() with the same pointer you received from allocation? That's one of the main clarifying points of this change—would be great to make sure that concept is in the documentation (here and in the other deallocate() methods).

natecook1000 · 2017-10-03T15:11:34Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  /// type `Element`.
+  ///
+  /// The resulting buffer references a region of memory that is bound to
+  /// `Element` and is `count * MemoryLayout<Element>.stride` bytes in size.


Let's add an example of allocation similar to what's in the UnsafePointer docs here:

/// The following example allocates a buffer that can store four `Int` /// instances and then initializes that memory with the elements of a range: /// /// let buffer = UnsafeMutableBufferPointer<Int>.allocate(capacity: 4) /// _ = buffer.initialize(from: 1...4) /// print(buffer[2]) /// // Prints "3"

jckarter · 2017-10-03T15:54:48Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please clean test

swift-ci · 2017-10-03T16:32:39Z

Build failed
Swift Test Linux Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

swift-ci · 2017-10-03T17:00:21Z

Build failed
Swift Test OS X Platform
Git Sha - 92e80cf35f2ad6312075cafe7d9321d711adb653

jckarter · 2017-10-03T18:51:03Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please clean test

airspeedswift

This PR needs a handful of changes to address source compatibility.

It's good to update all the tests to use the new form (which can be immediately available so long as they don't cause ambiguity with the compatibility versions), but there should also be some tests confirming the compatibility ones work too.

airspeedswift · 2017-10-10T18:46:58Z

stdlib/public/core/UnsafeRawPointer.swift.gyb

@@ -852,29 +861,34 @@ public struct Unsafe${Mutable}RawPointer : Strideable, Hashable, _Pointer {
    }
  }

+  @available(*, unavailable, renamed: "copyMemory(from:byteCount:)")


This needs to be gated by a version number. It should continue to work until Swift 5.

airspeedswift · 2017-10-10T18:51:03Z

stdlib/public/core/UnsafePointer.swift.gyb

  /// - Returns: A raw pointer to the same address as this pointer. The memory
  ///   referenced by the returned raw pointer is still bound to `Pointee`.
  @_inlineable
  @discardableResult
-  public func deinitialize(count: Int = 1) -> UnsafeMutableRawPointer {
+  public func deinitialize(count: Int) -> UnsafeMutableRawPointer {


This needs a compatibility shim to ensure you can still call it without an argument until 5.0

This can’t be overloaded because deinitialize(count:) with the default arg resolves to the same symbol as deinitialize(count:) without the default arg.

You can add a no-argument method that forwards to the new version, and make it obsoleted in 5.

isn’t that a completely new symbol?

Yes, but that’s fine.

airspeedswift · 2017-10-10T18:51:07Z

stdlib/public/core/UnsafePointer.swift.gyb

@@ -488,28 +486,48 @@ public struct ${Self}<Pointee>
  }

 %  if mutable:
+  @available(*, unavailable, renamed: "initialize(repeating:count:)")


This needs to be obsoleted: 5.0 instead of just unavailable.

xwu · 2017-10-10T23:25:17Z

stdlib/public/core/UnsafePointer.swift.gyb

@@ -488,28 +486,48 @@ public struct ${Self}<Pointee>
  }

 %  if mutable:
+  @available(swift, obsoleted: 5.0.0, renamed: "initialize(repeating:count:)")
+  public func initialize(to repeatedValue: Pointee, count:Int = 1) { 


Nit: space after count:.

Also, the function that's being obsoleted is technically initialize(to newValue: Pointee, count: Int = 1) (as opposed to repeatedValue). Doesn't strictly matter for compatibility, but the name is more correct in the circumstance that count defaults to 1.

glessard · 2017-10-11T11:18:24Z

stdlib/public/core/UnsafePointer.swift.gyb

  @_inlineable
-  public func initialize(to newValue: Pointee, count: Int = 1) {
+  public func initialize(repeating repeatedValue: Pointee, count: Int) {
    // FIXME: add tests (since the `count` has been added)
    _debugPrecondition(count >= 0,
      "${Self}.initialize(to:): negative count")


This _debugPrecondition message references the old argument label

atrick

Looks great. I just want to understand the choice of availability annotations better before accepting it.

atrick · 2017-10-17T03:29:33Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

@@ -329,7 +329,30 @@ public struct Unsafe${Mutable}BufferPointer<Element>
    self.init(start: slice.base.baseAddress! + slice.startIndex,
      count: slice.count)
  }
-%  end # !mutable
+  


Minor nit: I find it easier to read and maintain .gyb files when only closely related overloads are grouped under the same % if block. Your initializers are unrelated to the rebasing initializer.

i tried to avoid touching the gyb lines as much as possible mostly because i don’t know gyb

atrick · 2017-10-17T03:50:43Z

stdlib/public/core/UnsafeBufferPointer.swift.gyb

+  ///     value is also used as the return value for the `withMemoryRebound(to:_:)` 
+  ///     method.
+  /// - Returns: The return value, if any, of the `body` closure parameter.
+


There's an extra newline here.

atrick · 2017-10-17T04:44:02Z

stdlib/public/core/UnsafePointer.swift.gyb

+  @available(*, deprecated, message: "Swift currently only supports freeing entire heap blocks, use deallocate() instead")
+  public func deallocate(capacity _: Int) { 
+    self.deallocate()
+  }


@airspeedswift Do we also need to mark this obsolete in Swift 5 so we don't need to carry forward the symbol? (I'm not sure how these availability attributes are supposed to be used).

atrick · 2017-10-17T04:50:46Z

stdlib/public/core/UnsafeRawBufferPointer.swift.gyb

+  @available(*, unavailable, renamed: "allocate(byteCount:alignment:)")
+  public static func allocate(count: Int) -> UnsafeMutableRawBufferPointer { 
+    fatalError("unreachable") 
+  }


@airspeedswift I interpret unavailable as instantly obsoleted in all modes. (I can't find docs on these attributes.) Why don't we need source-compatibility in cases like this? Does it make a difference that we can use renamed?

atrick · 2017-10-17T05:05:55Z

stdlib/public/core/UnsafeRawPointer.swift.gyb

+    bytes size: Int, alignedTo: Int
+  ) -> UnsafeMutableRawPointer {
+    fatalError("unreachable")
+  }


Same question: Why not obsoleted: 5?

atrick · 2017-10-17T05:17:53Z

stdlib/public/core/UnsafeRawPointer.swift.gyb

+  @available(*, deprecated, message: "Swift currently only supports freeing entire heap blocks, use deallocate() instead")
+  public func deallocate(bytes _: Int, alignedTo _: Int) { 
+    self.deallocate()
+  }


In addition to deprecating, do we also need to obsolete this in 5?

i don’t know,,, the way i’ve always used @available is to deprecate stuff that’s being removed and unavailable–rename stuff that’s been renamed. that’s just the convention i follow in my projects, the swift book is not very helpful here

You can supply multiple @available attributes - that attribute is the first one documented here.

okay but it doesn’t say what the exact difference between unavailable and obsoleted and renamed is or when to use each one. i’ve just been going off of the example they have midway down the page

@available(*, unavailable, renamed: "MyRenamedProtocol")

Ok, so the swift-book says that you can use renamed with unavailable, but it actually works with the other availability attributes as well. I think we typically want to use obsoleted: 5, renamed: so that we have source compatibility in Swift 4 mode but aren't forced to provide those symbols in Swift 5. I'll need to check with @airspeedswift to be sure.

does that mean the legacy function implementations have to stay instead of being replaced with fatalError("unreachable")??

i changed all the unavailables to obsoleteds and i did my best to forward them to the actual implementations

natecook1000 · 2017-10-17T17:11:32Z

stdlib/public/core/UnsafeRawPointer.swift.gyb

+  public func initializeMemory<T>(
+    as type: T.Type, at offset: Int = 0, count: Int = 1, to repeatedValue: T
+  ) -> UnsafeMutablePointer<T> { 
+    _debugPrecondition(offset == 0,


This new precondition will break the behavior of existing code that uses a nonzero at parameter.

the behavior would already be broken anyway since the new implementation doesn’t take an offset parameter, so it wouldn’t get forwarded from the compatibility shim. The precondition just warns users about this.

nvm i just used (self + offset * MemoryLayout<T>.stride) in the shim body

Great solution! 👍

natecook1000 · 2017-10-17T17:19:03Z

stdlib/public/core/UnsafePointer.swift.gyb

@@ -439,22 +437,22 @@ public struct ${Self}<Pointee>
    Builtin.bindMemory(rawPtr, count._builtinWordValue, Pointee.self)
    return UnsafeMutablePointer(rawPtr)
  }
+
+  @available(swift, obsoleted: 5.0.0, message: "Swift currently only supports freeing entire heap blocks, use deallocate() instead")


We should deprecate all these methods that are going away, so users get information about the change even before they've migrated to Swift 5. You can add:

@available(swift, deprecated, renamed/message: "same as used for the obsoleted attribute")

Well, the compiler doesn't actually like that, but you can do even better. Add a deprecated parameter alongside the obsoleted one:

@available(swift, deprecated: 4.1, obsoleted: 5.0.0, message: "Swift currently only supports freeing entire heap blocks, use deallocate() instead")

did not know you could do that

atrick · 2017-10-17T17:58:22Z

@natecook1000 suggests using @available(swift, deprecated: 4.1, obsoleted: 5.0.0, message: "Swift currently only supports freeing entire heap blocks, use deallocate() instead")

That makes sense to me. @jrose-apple, is that right?

As long as we have compatibility shims for all the source breaking changes annotated with this attribute, then I'm ready to approve the changes. I think @airspeedswift also needs to approve the recent changes.

xwu · 2017-10-17T19:07:12Z

validation-test/stdlib/UnsafeBufferPointer.swift.gyb

@@ -746,6 +747,7 @@ UnsafeMutable${'Raw' if IsRaw else ''}BufferPointerTestSuite.test("subscript/${R
  defer { deallocateFor${Raw}Buffer(
      sliceMemory, count: replacementValues.count) }

+  // this produces a spurious compiler warning,, someone take a look lol?


Minor point, but can we clean up this comment before merge?

for some reason if the buffer on the line below is declared var the compiler complains that it’s never mutated, but if it’s declared let it doesn’t compile since a mutating member gets called on it.

it’s out of the scope of this proposal but it’s something we should come back to later and sort out

Sure; I was only talking about capitalization, punctuation, etc :)

jrose-apple · 2017-10-17T22:07:31Z

@natecook1000 suggests using @available(swift, deprecated: 4.1, obsoleted: 5.0.0, message: "Swift currently only supports freeing entire heap blocks, use deallocate() instead")

That makes sense to me. @jrose-apple, is that right?

That sounds good, although the grammarian in me says that the message should use a semicolon instead of a comma.

tayloraswift · 2017-10-18T00:20:55Z

the fangirl in me says that the message should use two commas in a row instead of one comma so compromise? 😂

jrose-apple · 2017-10-20T23:32:12Z

Not going to block the PR over it, for sure. :-)

airspeedswift

LGTM. Just one comment about a comment.

airspeedswift · 2017-10-26T16:19:21Z

stdlib/public/core/UnsafePointer.swift.gyb

  ///
-  /// - Parameter capacity: The amount of memory to deallocate, counted in
-  ///   instances of `Pointee`.
+  /// This pointer must be a pointer to a previously allocated memory block. 


Perhaps "to the start" of a previously allocated memory block, to be completely explicit.

atrick

I did not realize this PR was still open. I was only waiting for @airspeedswift's review of the @available annotations. There's nothing holding this up except for the rebasing work.

…rop all parameters from deallocation, adjust namings, and add repeated-value assignment methods

tayloraswift · 2017-11-07T00:47:11Z

this and the swift-corelibs-foundation patch should be fixed now

tayloraswift · 2017-11-14T21:35:38Z

any movement on this?

atrick · 2017-11-15T00:37:06Z

I think anyone can merge this. If you want me to do it, I'll have time this Friday to watch the bots and deal with any fallout.

tayloraswift · 2017-11-15T02:20:11Z

i mean besides xiaodi i think im the only one here who can’t commit so someone besides me is going to have to lol

xwu · 2017-11-15T03:13:53Z

Hehe, one day maybe, I'll get around to requesting commit permissions, but I'm in no hurry to take on that kind of responsibility :)

atrick · 2017-11-17T21:31:57Z

@swift-ci test.

swift-ci · 2017-11-17T23:49:50Z

Build failed
Swift Test OS X Platform
Git Sha - 8dabca1

tayloraswift · 2017-11-17T23:59:44Z

i really don’t know what just happened. the ci was building it fine before…

atrick · 2017-11-18T00:43:16Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please clean test

atrick · 2017-11-18T02:40:52Z

The test failure is not related to this PR. All PR testing is broken:
Failure: SILOptimizer/specialize_no_definition.sil

atrick · 2017-11-18T02:42:54Z

Hopefully Arnold fixed the problem:
#12998

atrick · 2017-11-18T02:49:25Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please clean test

swift-ci · 2017-11-18T03:37:07Z

Build failed
Swift Test OS X Platform
Git Sha - 8dabca1

atrick · 2017-11-18T05:26:34Z

Please test with the following PR:

swiftlang/swift-corelibs-foundation#1247

@swift-ci Please clean test

swift-ci · 2017-11-18T05:28:29Z

Build failed
Swift Test OS X Platform
Git Sha - 8dabca1

swift-ci · 2017-11-18T07:20:59Z

Build failed
Swift Test Linux Platform
Git Sha - 8dabca1

xwu reviewed Sep 30, 2017

View reviewed changes

gottesmm changed the title ~~SE 0184a implementation~~ [WIP] SE 0184a implementation. DON'T MERGE Oct 1, 2017

swiftlang deleted a comment from swift-ci Oct 2, 2017

natecook1000 self-requested a review October 2, 2017 22:41

tayloraswift mentioned this pull request Oct 2, 2017

Fix against se-0184a swiftlang/swift-corelibs-foundation#1247

Merged

natecook1000 reviewed Oct 3, 2017

View reviewed changes

jessesquires mentioned this pull request Oct 3, 2017

[90] Issue #90 - Oct 5, 2017 SwiftWeekly/swiftweekly.github.io#318

Closed

airspeedswift requested changes Oct 10, 2017

View reviewed changes

xwu reviewed Oct 10, 2017

View reviewed changes

glessard reviewed Oct 11, 2017

View reviewed changes

atrick requested changes Oct 17, 2017

View reviewed changes

natecook1000 reviewed Oct 17, 2017

View reviewed changes

xwu reviewed Oct 17, 2017

View reviewed changes

airspeedswift approved these changes Oct 26, 2017

View reviewed changes

atrick approved these changes Nov 6, 2017

View reviewed changes

implement SE 184: add allocation methods to Unsafe buffer pointers, d…

8dabca1

…rop all parameters from deallocation, adjust namings, and add repeated-value assignment methods

atrick merged commit c858808 into swiftlang:master Nov 18, 2017

SE 0184a implementation #12200

SE 0184a implementation #12200

Uh oh!

Conversation

tayloraswift commented Sep 30, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xwu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tayloraswift commented Oct 1, 2017

Uh oh!

gottesmm commented Oct 1, 2017

Uh oh!

gottesmm commented Oct 1, 2017

Uh oh!

swift-ci commented Oct 1, 2017

Uh oh!

swift-ci commented Oct 1, 2017

Uh oh!

tayloraswift commented Oct 2, 2017

Uh oh!

moiseev commented Oct 2, 2017

Uh oh!

moiseev commented Oct 2, 2017

Uh oh!

moiseev commented Oct 2, 2017 via email

Uh oh!

jckarter commented Oct 2, 2017

Uh oh!

jckarter commented Oct 2, 2017

Uh oh!

swift-ci commented Oct 2, 2017

Uh oh!

swift-ci commented Oct 2, 2017

Uh oh!

jckarter commented Oct 2, 2017

Uh oh!

swift-ci commented Oct 2, 2017

Uh oh!

jckarter commented Oct 3, 2017

Uh oh!

swift-ci commented Oct 3, 2017

Uh oh!

swift-ci commented Oct 3, 2017

Uh oh!

natecook1000 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

tayloraswift commented Sep 30, 2017 •

edited

Loading