Skip to content

Add Wasm and its features to SupportedPlatforms #373

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Add Wasm and its features to SupportedPlatforms #373

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
344ecfc
Add wasm and its features to SupportedPlatforms
MaxDesiatov Oct 28, 2020
b089903
Fix comment typo in `SupportedPlatforms.swift`
MaxDesiatov Oct 28, 2020
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
36 changes: 34 additions & 2 deletions Sources/PackageDescription/SupportedPlatforms.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,9 @@ public struct Platform: Encodable {
/// The WebAssembly System Interface platform.
@available(_PackageDescription, introduced: 5.3)
public static let wasi: Platform = Platform(name: "wasi")

/// The WebAssembly platform.
public static let wasm: Platform = Platform(name: "wasm")
}

/// A platform that the Swift package supports.
Expand All @@ -65,17 +68,20 @@ public struct Platform: Encodable {
/// target of a package's dependencies must be lower than or equal to the top-level package's
/// deployment target version for a particular platform.
public struct SupportedPlatform: Encodable {

/// The platform.
let platform: Platform

/// The platform version.
let version: String?

/// The platform features.
let features: Int64?

/// Creates supported platform instance.
init(platform: Platform, version: String? = nil) {
init(platform: Platform, version: String? = nil, features: Int64? = nil) {
self.platform = platform
self.version = version
self.features = features
}

/// Configures the minimum deployment target version for the macOS platform.
Expand Down Expand Up @@ -161,6 +167,10 @@ public struct SupportedPlatform: Encodable {
public static func watchOS(_ versionString: String) -> SupportedPlatform {
return SupportedPlatform(platform: .watchOS, version: SupportedPlatform.WatchOSVersion(string: versionString).version)
}

public static func wasm(_ features: WasmFeatures) -> SupportedPlatform {
return SupportedPlatform(platform: .wasm, features: features.rawValue)
}
}

/// An extension to the SupportedPlatform struct that defines major platform versions.
Expand Down Expand Up @@ -362,6 +372,28 @@ extension SupportedPlatform {
@available(_PackageDescription, introduced: 5.3)
public static let v7: WatchOSVersion = .init(string: "7.0")
}

/// The supported WebAssembly features.
public struct WasmFeatures: Encodable, OptionSet {
public init(rawValue: Int64) {
self.rawValue = rawValue
}

/// The underlying features representation.
public let rawValue: Int64

/// Minimum available feature set.
static let mvp = WasmFeatures([])

/// WebAssembly System Interface is available.
static let wasi = WasmFeatures(rawValue: 1 << 0)
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 wasi should be treated as OS in target triple instead of feature flag

Copy link
Author

Choose a reason for hiding this comment

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

How do we then distinguish between WASI with atomics and without them? Is WASI expected to be versioned?

Copy link
Author

Choose a reason for hiding this comment

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

Or, how do we indicate that these overlap? Say there's a package A with .wasm(.simd) requirement, but has no assumptions about WASI presence. Then there's another package B that assumes presence of WASI, but doesn't require SIMD. A package C depends on A and B. How do we express platform requirements for C in its Package.swift?

Copy link
Member

Choose a reason for hiding this comment

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

WASI is a versioned interface. (see also https://github.com/webassembly/wasi/blob/master/phases/README.md)

How do we then distinguish between WASI with atomics and without them?

They can be distinguished like below.

let package = Package(
    name: "SwiftWasmApp",
    platforms: [.wasi(.snapshot, features: [.atomics])]
)

let package = Package(
    name: "SwiftWasmApp",
    platforms: [.wasi(.snapshot)]
)

Copy link
Author

Choose a reason for hiding this comment

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

Right, and what about packages that don't require WASI, but still need specific Wasm features?

Copy link
Member

@kateinoigakukun kateinoigakukun Oct 29, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Users can know that a feature is enabled at source code level not package dependency graph level.

Especially if the top-level package doesn't need it, but some dependency deep down in the dependency tree does?

I see, hmm let me think more.

Copy link
Member

Choose a reason for hiding this comment

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

Also abusing the version string is not horrible, but I cast my vote for adding build invocation parameters.

Copy link
Author

Choose a reason for hiding this comment

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

Ok, I think that SwiftPM dependency tree checks and source level checks are separate and not mutually exclusive. Other platforms support both. How's about we consider adding source-level checks with the @available attribute? swiftlang/swift#34439 is one example of that. We still need to decide how we pass a list of features to it, or if we version Wasm in some way.

For versioning we could consider is year versions. As in, Wasm 2018 is MVP, Wasm 2019 is MVP + whatever was available in all browsers at the end of 2019 etc. This would be similar to how Babel versions ECMAScript.

WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

Combining the two suggestions, the manifest could indicate:

let package = Package(
    name: "SwiftWasmApp",
    platforms: [.wasm("atomics,simd")]

and SPM translates that into --experimental-wasm-features

Copy link
Author

Choose a reason for hiding this comment

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

Nice, I like it!


/// Shared linear memory and atomic memory access are available.
static let atomics = WasmFeatures(rawValue: 1 << 1)

/// Fixed-width SIMD is available.
static let simd = WasmFeatures(rawValue: 1 << 2)
}
}

fileprivate protocol AppleOSVersion {
Expand Down