Skip to content

Conversation

@github-actions
Copy link

This PR was automatically opened by a GitHub action. Review the changes included in this PR and determine if they should be included in the release branch. If yes, merge the PR. Otherwise revert changes that should not be included on this branch.

bkhouri and others added 12 commits December 16, 2025 15:03
Set the `SWIFT_FORCE_STATIC_LINK_STDLIB` build setting in SwiftBuild
accordingly to the command line argument and if it's not on Darwin.

In addition, set the SWIFT_RESOURCE_DIR setting as that is what the
Native build system does.

Fixes: #9320
Issue: rdar://163948614
Depends on: #9389 
Needs: swiftlang/swift-build#942
…ot build-time, search path (#9518)

This constrains a behavior I landed in #8199 so that it only includes
the `PrivateFrameworks` directory from Xcode's platform directory (when
present) as a **runtime** framework search path (via
`DYLD_FRAMEWORK_PATH`) and no longer includes it as a _build-time_
framework search path (via `-F <path>`).

### Motivation:

This is a follow-up to a change I made in #8199. Those changes had an
undesirable side effect of including private frameworks in all builds,
and means that when those frameworks are present at build time, they're
included in client builds and can be `import`'ed or linked. Exposing
those frameworks to clients at _build-time_ was not intended, and can
cause unexpected results or failures if (for example) those private
frameworks themselves contain unresolvable module imports.

However, platform private frameworks directories _should_ continue to be
included in runtime framework search paths, so they can be located and
loaded when referenced by public frameworks/libraries.

### Modifications:

- Introduce separate properties for build-time vs. runtime framework and
library search paths, so the two categories can be differentiated by
callers.
- Omit the private frameworks search path from the new build-time
frameworks property.
- Adopt the relevant new properties at both build and runtime usage
sites.

### Result:

After this change, I validated that:

- a local package build no longer contains the private frameworks search
path entry at build time, using `swift build --build-tests --verbose`,
and
- a local package test operation still includes the search path, using
`env DYLD_PRINT_ENV=1 swift test`.
Fix various tests so they pass on Windows

- also mark withKnownIssues tests as isIntermittent: true so that as we
  fix things in dependent packages (like swift-build) we don't break
  swiftPM CI
Adopt the new API on SWBBuildRequest

Depends on #9417 
Fixes: #9321

---------

Co-authored-by: Bassam Khouri <[email protected]>
This ensures that targets know to re-request the list of targets when
the underlyinf Swift Build server regenerates the build description
Change the underlying storage type from `Value?` to storing `Value`,
with optional-specific operations moved to constrained extensions.

This improves type safety by eliminating unnecessary optionality for
non-optional types.

This stronger type constraint makes it more difficult for the struct to
be misused. For instance in the current implementation the extension
method `increment()` will fail to increment if the user forgot to
initialize the `ThreadSafeBox` with a value. Now a value must be set
initially before increment is called.

Also this patch prevents a race condition in the `memoize` methods where
the call to the memoized `body` was not guarded by a lock which allowed
multiple threads to call memoize at once and produce inconsistent
results.

Finally, fix the subscript setter so it works properly with `structs`,
as the `if var value` and then value set will set the value on a copy,
not on the `self.underlying` struct. Now that the type is no longer
optional this unwrapping isn't necessary and we can set directly on the
value.
…ax (#9408)"

This reverts commit 41f7eea.

Resolved conflicts in:
	Utilities/build-using-self
Revert "Change AsyncProcess stdout/err reads to 4096 instead of Int.max (#9408)"
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.

7 participants