Use libSwiftPM 5.6 to parse manifests

[yonihemi]

Upgrades libSwiftPM from 5.5 to 5.6 + related dependencies' versions (tools-support-core and swift-argument-parser). Fixes #285.

This changes the parsing strategy to rely on libSwiftPM to directly invoke swiftc and parse a compiled manifests' output. While I expected the output of swift package dump-package to be more stable than PackageDescription's JSON output, the opposite is true, and at least between 5.5 and 5.6 that format is backwards compatible. We may have to revisit this if this internal format breaks.

Previous strategy

sequenceDiagram
carton w/ libSwiftPM->>SwiftWasm SwiftPM: (shell) swift package dump-package
SwiftWasm SwiftPM->>SwiftWasm swiftc: build manifest for host platform with host SDK
SwiftWasm swiftc->>SwiftWasm SwiftPM: compiled host manifest
SwiftWasm SwiftPM->>SwiftWasm SwiftPM: parse manifest output
SwiftWasm SwiftPM->>carton w/ libSwiftPM: JSON output
carton w/ libSwiftPM->>carton w/ libSwiftPM: Parse with libSwiftPM

Loading

New strategy

sequenceDiagram
carton w/ libSwiftPM->>SwiftWasm swiftc: build manifest for host platform with host SDK
SwiftWasm swiftc->>carton w/ libSwiftPM: compiled host manifest
carton w/ libSwiftPM->>carton w/ libSwiftPM: parse manifest output

Loading

Alternatives considered:

• Using libSwiftPM 5.6 to parse 5.6 dump-package output + copy parts of libSwiftPM 5.5 for parsing older dump-package output: This becomes unwieldy fast due to significant code changes with many different types, plus to avoid naming conflicts would need to be isolated to a separate module.
• Go back to our own parser: we'd still need to support at least 2 formats, plus we'd be missing a way to instantiate a proper Manifest object.

[MaxDesiatov]

Great, thank you so much! Do I understand correctly that this is compatible with 5.5 toolchains as well?

[yonihemi]

Great, thank you so much! Do I understand correctly that this is compatible with 5.5 toolchains as well?

Correct, tested with both 5.5 and 5.6.

[SDGGiesbrecht]

This strategy is compatible with tools version markers as far back as SwiftPM proper supports, but is only compatible with the corresponding patch version of the actual toolchain inside which it expects to reside. If it happens to work between 5.5 and 5.6 by accident, consider yourself lucky, and go ahead and use it for now. Just be aware that you will likely have to switch back to the dump-package strategy in the future if you intend to continue supporting multiple toolchains with the same installation of carton. (Having used SwiftPM this way myself since 4.1, I can confirm that it regularly breaks when new toolchains are released.)