Skip to content

Merge main 1d48e0a into release/6.2 #8488

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.

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 12 commits into from

Conversation

dschaefer2
Copy link
Member

Let's see if a manual merge of main into release/6.2 works

pmattos and others added 12 commits April 4, 2025 13:38
…g#8449)

### Motivation:
Some of the `SwiftBuildSupport/PIFBuilder.swift` encoding/decoding code
was using unsafe string keys. This replaces with proper typesafe keys.

This part of the ground work to support the new PIF builder in
`SwiftBuildSupport` (i.e., rdar://147527170).

### Modifications:
When conforming to `Codable`, replace string keys with `enum` based keys
instead.

### Result:
The resulting code is a tad safer and easier to understand :-)

Tracked by rdar://148546582.
…wiftlang#8441)

### Motivation:

The goal is to adopt the new `SwiftBuild.ProjectModel` API. This new API
provides a *typesafer* and *modern* way of building PIFs
programmatically.

This continues the work I started in PR swiftlang#8405, introducing now our new
PIF builder for packages.

### Modifications:

Replaces all `SwiftBuild.PIF` (aka, `SWBProjectModel.PIF`) API usage, in
`PackagePIFBuilder`, with the new `SwiftBuild.ProjectModel` API instead.

### Result:

`PackagePIFBuilder` is now modernized... but still not actually used.
This will come in my next pull request.

Tracked by rdar://147526957.
Some tests in Tests/SourceControlTests are passing on Windows since
upgrading the Git Version in the associated docker image, which was
completd in https://github.com/swiftlang/swift-docker/pulls/452

Enable the tests that are skipped.

Relates to: swiftlang#8433 
rdar://148248105
…swiftlang#8462)

This updates and clarifies the [Version-specific Manifest
Selection](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/Usage.md#version-specific-manifest-selection)
section of the usage documentation to clarify the behavior when having
either newer or older tools versions.

### Motivation:

In general, when using the versioned manifest feature, it's preferable
to have the unversioned `Package.swift` represent the newest-supported
tools version, and only use version-specific manifest files for older
versions. This provides a better workflow because it allows you to more
easily drop support for older versions when ready (by avoiding the need
to modify the unversioned file), among other benefits.

### Modifications:

- "Reverse" the example shown in this documentation by having the
unversioned file be newest.
- Modernize the version numbers shown in examples.
- Fix some non-inclusive language usages.
- Add a footnote with some helpful historical context, and giving a
recommendation.
Enable WorkspaceTests on Windows that, for some reason, previously
failed.

Relates: swiftlang#8433
rdar://148248105
Enable additional tests on Windows host platform

- Enable a few `AsyncProcessTests`
- Enable the lone skipped test in `EnvironmentTests`
- Enable the only skipped test in
    `Tests/SourceKitLSPAPITests/SourceKitLSPAPITests.swift`
- Enable the only skipped test in
    `Tests/BuildTests/BuildSystemDelegateTests.swift`
- Enable the lone skipped test in
    `Tests/BuildTests/LLBuildManifestBuilderTests.swift`
- Replace usages of `fixwin` with `AbsolutePath.pathString`

Related to: swiftlang#8433
rdar://148248105
Remove hardcoded WASI sysroot path derivation just for wasi-sysroot embedded in toolchains

### Motivation:

The previous implementation assumed there is $TOOLCHAIN_ROOT/share/wasi-sysroot when `--triple wasm32-unknown-wasi` is passed, but this is no longer the case with the [deprecation of the Wasm toolchain installation](swiftwasm/swift#5604) in favor of Swift SDKs.

Due to this unnecessary branch, when `--triple wasm32-unknown-wasi` is passed together with `--swift-sdk`, `--swift-sdk` is just ignored: swiftlang#8465

### Modifications:

This change removes the hardcoded path derivation for the WASI sysroot from the `SwiftSDK.deriveTargetSwiftSDK` method.

### Result:

When `--triple wasm32-unknown-wasi` is passed without `--swift-sdk`, no user visible change and they will keep getting the following:
```
error: emit-module command failed with exit code 1 (use -v to see invocation)
<unknown>:0: warning: libc not found for 'wasm32-unknown-wasi'; C stdlib may be unavailable
<unknown>:0: error: unable to load standard library for target 'wasm32-unknown-wasi'
```

When `--triple wasm32-unknown-wasi` is passed together with `--swift-sdk`, `--triple` is ignored and `--swift-sdk` is respected.
Until swiftlang#8223 is fixed copy some helpers from
`IntergrationTests/Source/IntegrationTests` to
`Test/_InternalTestSupport` so we can re-use the functionality.

Related to: swiftlang#8433
rdar://148248105
…8472)

We were including flags to hook up modulemaps and include files to C
library dependencies in macros and plugin tools through to the modules
that depend on those. This adds the capability to prune the depth first
searches through the dependencies to ensure these are skipped when
crossing macro and plugin boundaries.
Until swiftlang#8223 is fixed copy some helpers from
`IntergrationTests/Source/IntegrationTests` to
`Test/_InternalTestSupport` so we can re-use the functionality.

Related to: swiftlang#8433
rdar://148248105

Test with: swiftlang/swift#80717
@dschaefer2
Copy link
Member Author

@swift-ci please test

@shahmishal
Copy link
Member

@swift-ci test self hosted

2 similar comments
@shahmishal
Copy link
Member

@swift-ci test self hosted

@shahmishal
Copy link
Member

@swift-ci test self hosted

@shahmishal
Copy link
Member

Fixed swift-driver branch issue

swiftlang/swift-build#407

@shahmishal
Copy link
Member

Fixed llbuild branch
swiftlang/swift-build#409

@shahmishal
Copy link
Member

@swift-ci test self hosted

@dschaefer2
Copy link
Member Author

Will start over.

@dschaefer2 dschaefer2 closed this Apr 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants