OpenBSD support.

[3405691582]

OpenBSD support.

Checklist

• I've run tests to see all new and existing tests pass
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary (not necessary)

If you've made changes to gyb files

• I've run .script/generate_boilerplate_files_with_gyb and included updated generated files in a commit of this pull request (not applicable)

Motivation:

swift-crypto is a required dependency for swift-package-manager, and must build and run on OpenBSD.

Modifications:

OpenBSD support for cmake/swiftpm.

* Add to patterns for CMakeLists. Also provide a helpful error so future
  porters have a slightly better idea of what might need to be updated.

* Proactively reverse sense in some system name checks so they read as
  "if not Darwin". This is likely safer to do here than elsewhere since
  there are likely not going to be other platforms for which swift-crypto
  already exists.

* Add to Package.swift

ManagedBuffer.capacity is unavailable on OpenBSD.

ManagedBuffer.capacity depends on malloc introspection (e.g.,
`malloc_size`), which is not available on this platform -- and is thus
marked as such.

Here, SecureBytes uses a ManagedBuffer in Backing. We have capacity
tracked in the BackingHeader, and most of the references to the
ManagedBuffer.capacity property can be replaced with references to the
capacity in the header. However, since capacity in the header is marked
as internal which conflicts with some of the @inline functions, so we
must change those to @usableFromInline for the platform as well.

Add conditional for RandomBytes.

Required for tests to build on OpenBSD.

Result:

swift-crypto builds and runs on OpenBSD.

[Lukasa]

These cmakelists.txt files are autogenerated, so you'll need to modify the generation script and then re-run it to produce this output.

[3405691582]

I don't understand. The scripts don't seem to modify the CMakeLists, only the underlying source, which I'm not touching. If it helps, I can leave off the extra helpful error here. Could you elaborate a bit more?

[Lukasa]

Why were these dropped from @inlinable?

[3405691582]

I had to change these from @inlinable to @usableFromInline because the new allocatedCapacity computed property refers to BackingHeader which is internal; otherwise I would get a compiler error. If you mean the comments, then I missed there was a similar commenting convention for "private but usableFromInline" and added that back in now.

[Lukasa]

Ah, so let's push the computed property one layer out. We'd like the body of this method to be inlinable, so we can add another computed property in the outer type that is @usableFromInline, which can keep this method accessible.

[3405691582]

I'm not sure I follow, sorry. _withVeryUnsafeMutableBytes and _copyBytes are extensions on SecureBytes.Backing and right now allocatedCapacity is defined on SecureBytes.Backing. If I set _copyBytes and _withVeryUnsafeMutableBytes back to @inlinable and add an extra computed property on SecureBacking, I still get errors, so I think I'm misunderstanding something.

[Lukasa]

Hrm, if the two methods are on SecureBytes.Backing and allocatedCapacity is also on SecureBytes.Backing, merely making allocatedCapacity @usableFromInline should be enough to flip these back to @inlinable.

[3405691582]

The error specifically reads something like this (same for _withVeryUnsafeMutableBytes):

/tmp/swift-crypto/Sources/Crypto/Util/SecureBytes.swift:443:51: error: property 'allocatedCapacity' is internal and cannot be referenced from an '@inlinable' function
332 | 
333 |         @usableFromInline
334 |         var allocatedCapacity: Int {
    |             `- note: property 'allocatedCapacity' is not '@usableFromInline' or public
335 | #if os(OpenBSD)
336 |                 return self.header.capacity
    :
441 |     /* private but inlinable */ func _copyBytes<C: Collection>(_ bytes: C, at offset: Int) where C.Element == UInt8 {
442 |         precondition(offset >= 0)
443 |         precondition(offset + bytes.count <= self.allocatedCapacity)
    |                                                   `- error: property 'allocatedCapacity' is internal and cannot be referenced from an '@inlinable' function
444 | 
445 |         let byteRange = offset..<(offset + bytes.count)

[Lukasa]

That error seems...entirely wrong. It's @usableFromInline, the annotation is right here.

[3405691582]

I found an apparent workaround: adding the property to the same section that _copyBytes is in makes this work somehow.