@abertelrud thanks for reviewing! There's no rush, but do you mind merging on my behalf, I don't have commit access to this repo

@swift-ci please smoke test

What do you think about making it conditional on the presence of ../swift-syntax? That would make it be included in the toolchain, etc. We could have it print a warning if it is excluding the functionality that depends on SwiftSyntax.

Thanks for taking a look! I've added this check, plus a new flag, --skip-package-syntax to skip it even if SwiftSyntax is present. I figured that might be helpful if someone is working with a full checkout but doesn't otherwise need perfectly matching dependencies.

Seems fine to me, though I don't have a lot of context for why this was there in the first place (other than your description, which is very helpful).

We decided against requiring this bit for the ArgumentParser change.

@swift-ci please smoke test

This test sometimes fails due to what seem to be module rebuilding issues. The diagnostics are only shown if the test fails; they don't pollute the regular output.

Yes @abertelrud we can merge!

I think I want to modulate this statement ("all optional"): since the delegate itself is optional, it might make sense to define the "major" events that the delegate just has to implement, and then maybe some of the minor ones could be optional (have default implementations that don't do anything). Or should they all be optional for consistency, especially since any new ones that get added later will have to be optional for compatibility reasons (until libSwiftPM is properly versioned). WDYT?

I actually dislike the current pattern in SwiftPM where we have empty implementation for delegates to make them seem optional. sure, it makes life easier for the caller when they first add a delegate but it makes it very difficult to properly evolve the delegate API inc. deprecations as the default empty ones hide the fact that that API changed from the caller making these into runtime issues. in other words, I'd like to see us factor out all the default empty delegate extensions so that the caller can decide explicitly what to ignore and be notified when we deprecate delegate APIs.

@miggs597 do you feel this is ready to merge?

I think having a delegate that's 1:1 with the only current resolver makes sense to me, we can choose to not emit logs for every callback if we want to. I don't think we will know enough to have a differently shaped delegate until we would actually have more than one resolver implementation.

100%. As Boris says, the callbacks should reflect what's actually happening. Individual delegates can then easily choose to ignore some of them, as long as they are all optional.

I think I want to modulate this statement ("all optional"): since the delegate itself is optional, it might make sense to define the "major" events that the delegate just has to implement, and then maybe some of the minor ones could be optional (have default implementations that don't do anything). Or should they all be optional for consistency, especially since any new ones that get added later will have to be optional for compatibility reasons (until libSwiftPM is properly versioned). WDYT?

I think having a delegate that's 1:1 with the only current resolver makes sense to me, we can choose to not emit logs for every callback if we want to. I don't think we will know enough to have a differently shaped delegate until we would actually have more than one resolver implementation.

100%. As Boris says, the callbacks should reflect what's actually happening. Individual delegates can then easily choose to ignore some of them, as long as they are all optional.

This is the 5.5 nomination of https://github.com/apple/swift-package-manager/pull/3410 which makes it possible to have single-file source modules with a @main by taking the same approach as Xcode does when building such modules (also increasing compatibility of packages between SwiftPM and Xcode).

The original PR is https://github.com/apple/swift-package-manager/pull/3410 and has a lot more details.

This is the 5.5 nomination of https://github.com/apple/swift-package-manager/pull/3415 which fixes a problem serializing package manifests with ranged package dependencies.

@owenv This looks ready to merge at this point. Thanks again!

@abertelrud sure, that makes sense to me. I dropped the underscored target, but kept the ones for swift-build, swift-test, etc. since they're still useful when not using the install action.

Absolutely, I did not mean to suggest removing the existing executables, only not adding the new underscored one. The existing ones are very useful during debug builds (in fact I use them all the time when working on SwiftPM in Xcode, using the scheme that's autocreated for each of them — and I suspect others use them in this was as well).

Perhaps in the future once we can create arbitrary symlinks during a debug build (perhaps with a postbuild action) we'll be able to remove them, but that's a ways off.

@owenv The changes themselves look good to me, but I think the setting of the environment variable in the bootstrap script needs to be made conditional on whether or not SwiftSyntax is available — otherwise it will be somewhat difficult to test other parts of the bootstrap script on the desktop without having the right compiler checked out, etc.

In fact I haven't yet been able to get this to work with a swift-syntax checkout that ought to work in theory (even though that checkout does build cleanly on its own, with a matching compiler next to it).

What do you think about making it conditional on the presence of ../swift-syntax? That would make it be included in the toolchain, etc. We could have it print a warning if it is excluding the functionality that depends on SwiftSyntax.

@swift-ci please smoke test

This test sometimes fails due to what seem to be module rebuilding issues. The diagnostics are only shown if the test fails; they don't pollute the regular output.

@swift-ci test

With the version-bump of Yams in https://github.com/apple/swift/pull/36366, Yams 4.0.2 now actually expresses the dependency on Dispatch in its CMake config.

With the current behavior of passing -Ddispatch_DIR to its CMake build, we have the following problem on Linux:

• swift's build-script installs Dispatch into a just-built toolchain which we use to build SwiftPM, which will contain, among other things, the Dispatch .swiftmodule.
• The compiler workspace checkout of swift-corelibs-libdispatch also contains a copy of the Dispatch .swiftmodule.

Both of these will be found, leading to build failures like:

/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-main/swift-nightly-install/usr/lib/swift/dispatch/module.modulemap:1:8: error: redefinition of module 'Dispatch'
19:37:47 module Dispatch {
19:37:47        ^
19:37:47 /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-main/swift-corelibs-libdispatch/dispatch/module.modulemap:1:8: note: previously defined here
19:37:47 module Dispatch {
19:37:47        ^
19:37:47

We also cannot put off building libDispatch until SwiftPM is built, because the libDispatch dylib is required to link SwiftPM. Not passing -Ddispatch_DIR to Yams' CMake build causes it to successfully locate the Dispatch package in the just-built toolchain on its own.

(cherry picked from commit 6af862d3a7efb3108334be0d3e3e33641c91f267)

[One line description of your change]

Motivation:

[Explain here the context, and why you're making that change. What is the problem you're trying to solve.]

Modifications:

[Describe the modifications you've done.]

Result:

[After your change, what will change.]

I think having a delegate that's 1:1 with the only current resolver makes sense to me, we can choose to not emit logs for every callback if we want to. I don't think we know enough to have a differently shaped delegate until we would actually have more than one resolver implementation.

@swift-ci please test linux