Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions stdlib/public/core/KeyPath.swift
Original file line number Diff line number Diff line change
Expand Up @@ -159,6 +159,27 @@ public class AnyKeyPath: Hashable, _AppendKeyPath {
let base = UnsafeRawPointer(Builtin.projectTailElems(self, Int32.self))
return try f(KeyPathBuffer(base: base))
}

@_inlineable // FIXME(sil-serialize-all)
@_versioned // FIXME(sil-serialize-all)
internal var _storedInlineOffset: Int? {
return withBuffer {
var buffer = $0
var offset = 0
while true {
let (rawComponent, optNextType) = buffer.next()
switch rawComponent.header.kind {
case .struct:
offset += rawComponent._structOrClassOffset

case .class, .computed, .optionalChain, .optionalForce, .optionalWrap:
return .none
}

if optNextType == nil { return .some(offset) }
}
}
}
}

/// A partially type-erased key path, from a concrete root type to any
Expand Down
37 changes: 37 additions & 0 deletions stdlib/public/core/MemoryLayout.swift
Original file line number Diff line number Diff line change
Expand Up @@ -162,4 +162,41 @@ extension MemoryLayout {
public static func alignment(ofValue value: T) -> Int {
return MemoryLayout.alignment
}

/// Returns the offset of an inline stored property of `T` within the
/// in-memory representation of `T`.
///
/// If the given `key` refers to inline storage within the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this initial paragraph could focus on the happy path: "If the given key refers to inline, directly addressable storage within the in-memory representation of T, the the return value…". After the example you have below, with root and value, we could use your description here of what might disqualify a property from being measured in this way, with an example type like:

struct ProductCategory {
    var name: String
    var updateCounter: Int
    var products: [Product] {
        didSet { updateCounter += 1 }
    }
    var productCount: Int {
        return products.count
    }
    var someAbstractedProperty: () -> () // I can't think of a good example here
}

And then we could point out the valid and invalid properties either in comments or in text. If I'm understanding this right, updateCounter and name would be safe, but accessing properties of name wouldn't—I don't think I included a non-inline property. What do you think?

/// in-memory representation of `T`, and the storage is directly
/// addressable (meaning that accessing it does not need to trigger any
/// `didSet` or `willSet` accessors, perform any representation changes
/// such as bridging or closure reabstraction, or mask the value out of
/// overlapping storage as for packed bitfields), then the return value
/// is a distance in bytes that can be added to a pointer of type `T` to
/// get a pointer to the storage accessed by `key`. If the return value is
/// non-nil, then these formulations are equivalent:
///
/// var root: T, value: U
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to have four spaces of indentation (five including the initial space after the triple-slash) for a code sample to be recognized. Within the code sample, we also use four-space indentation instead of the stdlib-standard two.

/// var key: WritableKeyPath<T, U>
/// // Mutation through the key path...
/// root[keyPath: \.key] = value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need the \. here and below, since key is a key path instance, not the path itself.

/// // ...is exactly equivalent to mutation through the offset pointer...
/// withUnsafePointer(to: &root) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be withUnsafeMutablePointer since they're modifying an underlying value.

/// (UnsafeMutableRawPointer($0) + MemoryLayout<T>.offset(of: \.key))
/// // ...which can be assumed to be bound to the target type
/// .assumingMemoryBound(to: U.self).pointee = value
/// }
///
/// - Parameter key: A key path referring to storage that can be accessed
/// through a value of type `T`.
/// - Returns: The offset in bytes from a pointer to a value of type `T`
/// to a pointer to the storage referenced by `key`, or `nil` if no
/// such offset is available for the storage referenced by `key`, such as
/// because `key` is computed, has observers, requires reabstraction, or
/// overlaps storage with other properties.
@_inlineable // FIXME(sil-serialize-all)
@_transparent
public static func offset(of key: PartialKeyPath<T>) -> Int? {
return key._storedInlineOffset
}
}
26 changes: 26 additions & 0 deletions test/stdlib/KeyPath.swift
Original file line number Diff line number Diff line change
Expand Up @@ -666,6 +666,32 @@ keyPath.test("subscripts") {
expectEqual(base[keyPath: ints_be], (17 + 38).bigEndian)
}

struct NonOffsetableProperties {
// observers
var x: Int { didSet {} }
// reabstracted
var y: () -> ()
// computed
var z: Int { return 0 }
}

keyPath.test("offsets") {
let SLayout = MemoryLayout<S<Int>>.self
expectNotNil(SLayout.offset(of: \S<Int>.x))
expectNotNil(SLayout.offset(of: \S<Int>.y))
expectNotNil(SLayout.offset(of: \S<Int>.z))
expectNotNil(SLayout.offset(of: \S<Int>.p))
expectNotNil(SLayout.offset(of: \S<Int>.p.x))
expectNotNil(SLayout.offset(of: \S<Int>.p.y))
expectNotNil(SLayout.offset(of: \S<Int>.c))
expectNil(SLayout.offset(of: \S<Int>.c.x))

let NOPLayout = MemoryLayout<NonOffsetableProperties>.self
expectNil(NOPLayout.offset(of: \NonOffsetableProperties.x))
expectNil(NOPLayout.offset(of: \NonOffsetableProperties.y))
expectNil(NOPLayout.offset(of: \NonOffsetableProperties.z))
}

// SR-6096

protocol Protocol6096 {}
Expand Down