{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":741591376,"defaultBranch":"main","name":"swift-package-manager","ownerLogin":"ian-twilightcoder","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2024-01-10T17:57:38.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/14132058?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1705539606.0","currentOid":""},"activityList":{"items":[{"before":"017192c2bf1be840a1585cafae7f6b74d9db7000","after":"d811fafe6290d710976cb5e6f999a004cbb9dd1c","ref":"refs/heads/main","pushedAt":"2024-04-17T00:22:51.000Z","pushType":"push","commitsCount":12,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Add `UndirectedGraph` and `DirectedGraph` data structures (#7460)\n\n`DirectedGraph` can be used to represent the existing modules graph in the `PackageGraph` module hopefully with better performance due to reduced number of allocations. `UndirectedGraph` could represent a new linkage graph concept, which would help with breaking dependency cycles for certain packages with products that don't have a linkage cycle.\r\n\r\nI started with an adjacency list in a directed graph implementation, but then proceeded to an undirected graph where adjacency matrix seemed obviously more performant when adding edges: just flipping two bits in the matrix instead of adding potential array (re-)allocations with the list.\r\n\r\nI'm unsure though if either is a clear win in all cases, adjacency matrix may be fast at adding edges, but not the fastest for different kinds of graphs analysis and lookups. Keeping both implementations for future reference.","shortMessageHtmlLink":"Add UndirectedGraph and DirectedGraph data structures (apple#7460)"}},{"before":"f4ab9a43f3cfbb8f184043435f925b67b0070f36","after":"017192c2bf1be840a1585cafae7f6b74d9db7000","ref":"refs/heads/main","pushedAt":"2024-04-10T03:04:42.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Bump `swift-syntax` in template to `600.0.0-latest` (#7443)\n\nrdar://124160537","shortMessageHtmlLink":"Bump swift-syntax in template to 600.0.0-latest (apple#7443)"}},{"before":"601d040cb7a060895a940e3d989138667e49cff0","after":"f4ab9a43f3cfbb8f184043435f925b67b0070f36","ref":"refs/heads/main","pushedAt":"2024-04-04T22:03:56.000Z","pushType":"push","commitsCount":16,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"[PubGrub] Avoid resolving package versions twice in presence of prebuilt libraries (#7436)\n\nIntegrate information about versions of prebuilt libraries into the solver\r\nand prioritize these versions when making decisions if they meet all of\r\nthe requirements of undecided terms.\r\n\r\nThis helps solver to avoid fetching and at the same time allows partial\r\nmatches on prebuilt libraries with fallback to package provided versions.","shortMessageHtmlLink":"[PubGrub] Avoid resolving package versions twice in presence of prebu…"}},{"before":"a809fb546ad6e50257e522b518a9b848ff86aecc","after":"601d040cb7a060895a940e3d989138667e49cff0","ref":"refs/heads/main","pushedAt":"2024-03-27T00:23:33.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"On Darwin, allow XCTest to be missing if we're only building swift-testing tests. (#7426)\n\nThis PR removes the constraint on Darwin that XCTest.framework must be\r\npresent in order to build tests using swift-testing. On Darwin, XCTest\r\nis included as a framework inside Xcode, but if a developer installs the\r\nXcode Command Line Tools instead of the full IDE, XCTest is not\r\nincluded. They then get a diagnostic of the form:\r\n\r\n> error: XCTest not available: terminated(1): /usr/bin/xcrun --sdk\r\nmacosx --show-sdk-platform-path output:\r\n> xcrun: error: unable to lookup item 'PlatformPath' from command line\r\ntools installation\r\n> xcrun: error: unable to lookup item 'PlatformPath' in SDK\r\n'/Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk'\r\n\r\nWhich is a poor experience if they aren't even using XCTest.\r\n\r\nThis change, as a (positive) side effect, suppresses the same diagnostic\r\nwhen running commands that are not usually dependent on the presence of\r\nXCTest such as `swift build`.\r\n\r\nNote that swift-corelibs-xctest is not supported on Darwin, so\r\ninstalling the Xcode Command Line Tools and adding an explicit\r\ndependency on swift-corelibs-xctest will not produce a functional test\r\ntarget bundle. Supporting swift-corelibs-xctest on Darwin is a potential\r\nfuture direction.\r\n\r\nAutomated testing for this change is difficult because it relies on a\r\nbuild environment that is not supported in CI (namely the presence of\r\nthe CL tools but not Xcode nor XCTest.framework.) I have manually tested\r\nthe change against swift-testing's own test target.\r\n\r\nA separate PR will be necessary in swift-testing to remove some\r\nremaining XCTest dependencies. Those changes are not covered by this PR.\r\n\r\nResolves rdar://125372431.","shortMessageHtmlLink":"On Darwin, allow XCTest to be missing if we're only building swift-te…"}},{"before":"d3ee3f63ca6ccdd0f8672a9a0d5714dbdb00d4aa","after":"a809fb546ad6e50257e522b518a9b848ff86aecc","ref":"refs/heads/main","pushedAt":"2024-03-25T21:24:05.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"PackageModelTests: fix warnings (#7421)\n\nResolve warnings in `Tests/PackageModelTests/MinimumDeploymentTargetTests.swift` .\r\n\r\n### Motivation:\r\n\r\n3 warnings were displayed indicating that a deprecated function is being\r\nused and suggesting the use of an alternative function.\r\n\r\n### Modifications:\r\n\r\nFollowing the suggestion, the warning was resolved.\r\n\r\n### Result:\r\n\r\nThe following warnings have been resolved:\r\n\r\n> `init(arguments:environment:exitStatus:output:stderrOutput:)` is\r\ndeprecated: use\r\n`init(arguments:environmentBlock:exitStatus:output:stderrOutput:)`","shortMessageHtmlLink":"PackageModelTests: fix warnings (apple#7421)"}},{"before":"adb8ea043357818da7609d41fd92327eb5b34fb6","after":"d3ee3f63ca6ccdd0f8672a9a0d5714dbdb00d4aa","ref":"refs/heads/main","pushedAt":"2024-03-21T04:40:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Fix a memory leak in `DownloadTaskManager` and `DataTaskManager` (#7408)\n\n`DownloadTaskManager` had a strong reference to `URLSession`, which\r\nretained its delegate, which was the `DownloadTaskManager`. This formed\r\na retain cycle.\r\n\r\nMake the reference from `URLSession` to the delegate weak and only keep\r\n`DownloadTaskManager` alive as long as `DownloadTask`s need it. This\r\ncauses the `DownloadTaskManager` to be deallocated once nobody holds a\r\nreference to it anymore and all the tasks it manages are finished.\r\n\r\nFinally, we need to call `invalidate` on the `URLSession` to tell it\r\nthat we’re done and that it should release its delegate (which is now\r\nthe `WeakDownloadTaskManager`wrapper).\r\n\r\nThis retain cycle was causing a leak in sourcekit-lsp. I verified that\r\nthe leak no longer exists with this patch.\r\n\r\nrdar://125012584","shortMessageHtmlLink":"Fix a memory leak in DownloadTaskManager and DataTaskManager (app…"}},{"before":"8268caa411b45fde7d886c2e7fc7982ae277040c","after":"adb8ea043357818da7609d41fd92327eb5b34fb6","ref":"refs/heads/main","pushedAt":"2024-03-20T19:36:47.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Write output-file-map.json atomically (#7406)\n\nThere are two subtle changes in behavior here:\r\n- This call will fail if the file system doesn’t support atomic\r\noperations. I’m not sure if we need to support file systems that don’t\r\nallow atomic operations here.\r\n\r\nrdar://124727242","shortMessageHtmlLink":"Write output-file-map.json atomically (apple#7406)"}},{"before":"5185c0395aefd327e5ed669f4a88427fc8123f20","after":"8268caa411b45fde7d886c2e7fc7982ae277040c","ref":"refs/heads/main","pushedAt":"2024-03-14T17:35:11.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Fix XCTest entrypoint for WASI by making it async (#7400)","shortMessageHtmlLink":"Fix XCTest entrypoint for WASI by making it async (apple#7400)"}},{"before":"1d0be84d3f52bf956335422dd80a09021a63b18d","after":"5185c0395aefd327e5ed669f4a88427fc8123f20","ref":"refs/heads/main","pushedAt":"2024-03-04T23:39:26.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Hide more llbuild-specific APIs (#7387)\n\nThese APIs should not be marked `public` to prevent SwiftPM clients from\r\nadopting them by accident.","shortMessageHtmlLink":"Hide more llbuild-specific APIs (apple#7387)"}},{"before":"f042ffdd9cefdf62859757f4bc586567147a3a14","after":"1d0be84d3f52bf956335422dd80a09021a63b18d","ref":"refs/heads/main","pushedAt":"2024-03-02T03:53:31.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Remove uses of `temp_await` from `SwiftTestCommand` (#7382)\n\nThis prevents possible deadlocks that can be caused by blocking Swift Concurrency threads with semaphores.","shortMessageHtmlLink":"Remove uses of temp_await from SwiftTestCommand (apple#7382)"}},{"before":"31bc8087b42e8d2a586bfc508594103ce47dde7d","after":"f042ffdd9cefdf62859757f4bc586567147a3a14","ref":"refs/heads/main","pushedAt":"2024-02-28T18:57:37.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Enable `AccessLevelOnImport` in `SourceKitLSPAPI` (#7366)\n\nThis prevents unnecessary API details from leaking outside of the\r\nSwiftPM package via `SourceKitLSPAPI` product.","shortMessageHtmlLink":"Enable AccessLevelOnImport in SourceKitLSPAPI (apple#7366)"}},{"before":"cae580e9a2c7d32ece1ad08c7e802c3bc27dc32a","after":"31bc8087b42e8d2a586bfc508594103ce47dde7d","ref":"refs/heads/main","pushedAt":"2024-02-24T02:33:23.000Z","pushType":"push","commitsCount":16,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Fix `package` access modifier in XCBuild support (#7258)\n\n`package` access modifier was previously not supported in `swift build\r\n--build-system xcode`. This causes build issues when attempting to\r\nproduce Universal binaries for SwiftPM, for example in this job\r\nhttps://ci.swift.org/job/swift-PR-source-compat-suite-debug-macos/1297/consoleFull.\r\n\r\nThe reason was that `-package-name` option was not added to\r\n`OTHER_SWIFT_FLAGS` in `PIFBuilder.swift`. Additionally, in llbuild\r\nsupport code we were shelling out to Swift Driver for every target to\r\ncheck whether `-package-name` is supported. Now with `-package-name`\r\noptions calculation generalized across build systems, Swift Driver\r\nchecks are done once per `BuildParameters` initialization, which reduces\r\nexcessive shelling for llbuild.\r\n\r\nResolves rdar://120925895.","shortMessageHtmlLink":"Fix package access modifier in XCBuild support (apple#7258)"}},{"before":"9131d8de0ca2adc2da0b332d532edbfe8ecdbb63","after":"cae580e9a2c7d32ece1ad08c7e802c3bc27dc32a","ref":"refs/heads/main","pushedAt":"2024-02-16T20:30:41.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Support for prebuilt packages in the SDK (#7337)\n\nThis should allow satisfying a package dependency with a package in the\r\nSDK (or toolchain) based on metadata. If the given prebuilt library is\r\nversion-compatible, we essentially elide the dependency from the graph.\r\nIf it is not, we will fetch and build the dependency as normal. If a\r\nlibrary with associated metadata is linked without a corresponding\r\npackage dependency, we'll emit a warning.","shortMessageHtmlLink":"Support for prebuilt packages in the SDK (apple#7337)"}},{"before":"6bcbf11476c5be39fb308ab50db72cc75a5cb103","after":"9131d8de0ca2adc2da0b332d532edbfe8ecdbb63","ref":"refs/heads/main","pushedAt":"2024-02-15T00:26:15.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Add hidden `--ignore-lock` escape hatch (#7338)\n\nThis is obviously dangerous, but arguably has been the default behavior\r\nof SwiftPM for many years, so offering an escape hatch seems\r\nappropriate.","shortMessageHtmlLink":"Add hidden --ignore-lock escape hatch (apple#7338)"}},{"before":"02f047a1856517679f44a3653d4e67cc54330aff","after":"6bcbf11476c5be39fb308ab50db72cc75a5cb103","ref":"refs/heads/main","pushedAt":"2024-02-06T22:20:54.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Bring back \"Lock scratch directory during tool execution\" (#7291)\n\nThis reverts commit e92df2d2a0c639a8f478f80d2838370d451de5da and brings\r\nback the changes from #7269.","shortMessageHtmlLink":"Bring back \"Lock scratch directory during tool execution\" (apple#7291)"}},{"before":"3e8328e3de533dd1ed570aee83a90d3b20fdb5fe","after":"02f047a1856517679f44a3653d4e67cc54330aff","ref":"refs/heads/main","pushedAt":"2024-01-31T05:52:50.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Fix logging of \"Running...\" for plugins (#7303)","shortMessageHtmlLink":"Fix logging of \"Running...\" for plugins (apple#7303)"}},{"before":"e93079640ab6f8d2cfebbae561f4e26078ae31bd","after":"3e8328e3de533dd1ed570aee83a90d3b20fdb5fe","ref":"refs/heads/main","pushedAt":"2024-01-26T22:57:10.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Clean up product dependency API (#7298)\n\nAs part of\r\nhttps://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md,\r\na new API with an optional `package` parameter was accidentally added.\r\nWe can safely remove this API since #4203 added validation that\r\nprohibited the use of product declarations without a package anyway. As\r\npart of this, I also cleaned up that diagnostic since \"unknown package\r\n'unknown package name'\" looks quite ugly.\r\n\r\nrdar://114303935\r\nfixes #7158","shortMessageHtmlLink":"Clean up product dependency API (apple#7298)"}},{"before":"34efc0bfe9d40d9a019644ac8fcd0b852c491dfe","after":"e93079640ab6f8d2cfebbae561f4e26078ae31bd","ref":"refs/heads/main","pushedAt":"2024-01-24T21:13:43.000Z","pushType":"push","commitsCount":11,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Filter `codesign` messages (#7285)\n\nRight now we end up with this output on relink:\r\n\r\n```\r\n/Users/neonacho/Projects/public/swift-package-manager/.build/arm64-apple-macosx/debug/swift-bootstrap: replacing existing signature\r\n```\r\n\r\nThis change specifically filters any output from `codesign` commands\r\nwhich haven't failed and we aren't in verbose mode.\r\n\r\nThis should eventually be possible at the command level, but for the\r\ntime being this allows us to avoid shipping SwiftPM with this messy\r\noutput.\r\n\r\nrdar://118937939","shortMessageHtmlLink":"Filter codesign messages (apple#7285)"}},{"before":"3ef830dddff459e569d6e49c186c3ded33c39bcc","after":"34efc0bfe9d40d9a019644ac8fcd0b852c491dfe","ref":"refs/heads/main","pushedAt":"2024-01-20T05:00:29.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Fix `./Utilities/soundness.sh` regressions (#7260)","shortMessageHtmlLink":"Fix ./Utilities/soundness.sh regressions (apple#7260)"}},{"before":"3baeee5fa467c810436f52fc341641eb9c922a1d","after":"3ef830dddff459e569d6e49c186c3ded33c39bcc","ref":"refs/heads/main","pushedAt":"2024-01-18T19:44:27.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"command plugins: Inherit SwiftPM's --configuration flag in packageManager.build (#7262)\n\nThis commit makes it possible for a build run on behalf of a command\r\nplugin to inherit the build configuration (debug or release) set for the\r\nwhole `swift package` run using the `--configuration` flag.\r\n\r\n ### Motivation:\r\n\r\nWhen a command plugin asks for a target to be built by calling\r\n`packageManager.build`, it must specify a release or debug build. If no\r\nconfiguration is given, debug is the default. This overrides any\r\nconfiguration specified by the user with `swift package -c\r\n`.\r\n\r\nA command plugin might often be used as an alterative entry point to\r\nSwift PM, responsible for building a target and then processing it in\r\nsome way to generate the final product. The user might run `swift\r\npackage -c release some-plugin --target some-target`, expecting a\r\nrelease build of target to be made, but currently the result will be a\r\ndebug binary if the plugin uses the default options.\r\n\r\n ### Modifications:\r\n\r\n* Added a new `.inherit` option for packageManager.build's\r\n`configuration` argument.; `.debug` remains the default, as before.\r\n* Added a test to verify that plugin-initiated builds are of the correct\r\ntype.\r\n\r\n ### Result:\r\n\r\nA command plugin can request a target build matching the configuration\r\nspecified on the SwiftPM command line. The default is still to make a\r\ndebug build, however in future we might change this to inherit the\r\noverall SwiftPM configuration.\r\n\r\n ### Alternatives:\r\n\r\nA command plugin does not currently seem to have access to SwiftPM's\r\nbuild configuration. We could pass this information to the plugin,\r\nallowing the plugin author to pass it back in the `packageManager.build`\r\ncall. This would be a less invasive change to SwiftPM, however the\r\napproach in this commit makes it easier to change the default to\r\n.inherit in the future.","shortMessageHtmlLink":"command plugins: Inherit SwiftPM's --configuration flag in packageMan…"}},{"before":"5388367933c71ddd4a4a50098a9c7ec36d249bad","after":null,"ref":"refs/heads/no-darwin-cxx-modules","pushedAt":"2024-01-18T01:00:06.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"}},{"before":"02a0017939d114bd0426549b0a57c135384963ae","after":"5388367933c71ddd4a4a50098a9c7ec36d249bad","ref":"refs/heads/no-darwin-cxx-modules","pushedAt":"2024-01-17T21:43:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Some C++ packages fail to build on Apple platforms\n\n`-fmodules` doesn't usually do anything in Apple clang for C++ compilation, `-fcxx-modules` needs to be passed as well. However, pure C++ (not Objective-C++) and a new enough dialect on some versions of Apple clang will implicitly enable `-fcxx-modules`, enabling clang modules, and causing errors. Stop passing `-fmodules` for C++ compilation.\n\nrdar://121056905","shortMessageHtmlLink":"Some C++ packages fail to build on Apple platforms"}},{"before":"52f0d69e1af2659f59b645ee94ad2645096802d9","after":"02a0017939d114bd0426549b0a57c135384963ae","ref":"refs/heads/no-darwin-cxx-modules","pushedAt":"2024-01-17T21:42:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Some C++ packages fail to build on Apple platforms\n\n`-fmodules` doesn't usually do anything in Apple clang for C++ compilation, `-fcxx-modules` needs to be passed as well. However, pure C++ (not Objective-C++) and a new enough dialect on some versions of Apple clang will implicitly enable `-fcxx-modules`, enabling clang modules, and causing errors. Stop passing `-fmodules` for C++ compilation.","shortMessageHtmlLink":"Some C++ packages fail to build on Apple platforms"}},{"before":null,"after":"52f0d69e1af2659f59b645ee94ad2645096802d9","ref":"refs/heads/no-darwin-cxx-modules","pushedAt":"2024-01-17T21:39:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Some C++ packages fail to build on Apple platforms\n\n`-fmodules` doesn't usually do anything in Apple clang for C++ compilation, `-fcxx-modules` needs to be passed as well. However, pure C++ (not Objective-C++) and a new enough dialect on some versions of Apple clang will implicitly enable `-fcxx-modules`, enabling clang modules, and causing errors. Stop passing `-fmodules` for C++ compilation.","shortMessageHtmlLink":"Some C++ packages fail to build on Apple platforms"}},{"before":"b3d17fa87eb453a054cc0ebee65101aacb9ee5c5","after":"3baeee5fa467c810436f52fc341641eb9c922a1d","ref":"refs/heads/main","pushedAt":"2024-01-17T21:15:37.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Fix `PackageGraph` traversal performance regressions (#7248)\n\nThis restores the performance of traversal of deep package graphs\r\npreviously available when `ResolvedTarget`, `ResolvedProduct`, and\r\n`ResolvedPackage` were reference types. Now instead of recursively\r\napplying `Hashable` and `Equatable` conformances to all properties in\r\ngraph's node, we only hash and compare for equality their identities\r\ndefined by `Identifiable`.\r\n\r\nUses of `Set` on these types are now replaced with the new\r\n`IdentifiableSet` type, which uses a dictionary of `[Element.ID:\r\nElement]` as its storage.\r\n\r\nThe main benefit of this approach is that build triple of\r\n`ResolvedProduct` and `ResolvedTarget` is now a part of their identity.\r\nThus we can still use value types, while the same `Target` from\r\n`PackageModel` instantiated as two different `ResolvedTarget`s with\r\ndifferent `BuildTriples` will have different identities.\r\n\r\nResolves rdar://120861833\r\nResolves rdar://120711211","shortMessageHtmlLink":"Fix PackageGraph traversal performance regressions (apple#7248)"}},{"before":"2394eb7c9455d6e67e0719238e24252affaa4540","after":"b3d17fa87eb453a054cc0ebee65101aacb9ee5c5","ref":"refs/heads/main","pushedAt":"2024-01-13T01:07:59.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Linux packages fail to build with LLVM 18 and Apple 2023 versions of clang (#7241)\n\nNewer versions of clang add builtin modules for its C Standard Library\r\nheaders. This creates problems* when building with a single module map\r\nthat tries to absorb all of the OS/SDK dependencies, which is what all\r\nnon-Apple platforms currently do in SwiftPM.\r\n\r\nThis works for Swift targets because the Swift compiler injects module\r\nmaps via vfs for non-Apple platforms. However, clang doesn't do anything\r\nsimilar for C-based targets, and so they fail to build.\r\n\r\nFor now, don't build with modules for any SwiftPM C-based targets on\r\nnon-Apple platforms.\r\n\r\n\\* Some problems are module cycles and headers being absorbed into\r\nunexpected modules. clang modules generally expect that OS/SDK headers\r\nare covered by module maps, and _not_ absorbed into whatever module\r\nhappens to include them first.\r\n\r\nrdar://120716498","shortMessageHtmlLink":"Linux packages fail to build with LLVM 18 and Apple 2023 versions of …"}},{"before":"1ada66b6a502e86d23ffac7b61db82d1a575dbe5","after":null,"ref":"refs/heads/only-darwin-modules","pushedAt":"2024-01-12T23:56:16.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"}},{"before":"90fcf1e9398b324a959ee7a9c820642381e168be","after":"1ada66b6a502e86d23ffac7b61db82d1a575dbe5","ref":"refs/heads/only-darwin-modules","pushedAt":"2024-01-12T19:22:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Linux packages fail to build with LLVM 18 and Apple 2023 versions of clang\n\nNewer versions of clang add builtin modules for its C Standard Library headers. This creates problems* when building with a single module map that tries to absorb all of the OS/SDK dependencies, which is what all non-Apple platforms currently do in SPM.\n\nThis works for Swift targets because the Swift compiler injects module maps via vfs for non-Apple platforms. However, clang doesn't do anything similar for C-based targets, and so they fail to build.\n\nFor now, don't build with modules for any SPM C-based targets on non-Apple platforms.\n\n* Some problems are module cycles and headers being absorbed into unexpected modules. clang modules generally expect that OS/SDK headers are covered by module maps, and _not_ absorbed into whatever module happens to include them first.\n\nrdar://120716498","shortMessageHtmlLink":"Linux packages fail to build with LLVM 18 and Apple 2023 versions of …"}},{"before":"601bfd88415513c3e40e535c46acd89237f34d85","after":"90fcf1e9398b324a959ee7a9c820642381e168be","ref":"refs/heads/only-darwin-modules","pushedAt":"2024-01-12T19:13:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Linux packages fail to build with LLVM 18 and Apple 2023 versions of clang\n\nNewer versions of clang add builtin modules for its C Standard Library headers. This creates problems* when building with a single module map that tries to absorb all of the OS/SDK dependencies, which is what all non-Apple platforms currently do in SPM.\n\nThis works for Swift targets because the Swift compiler injects module maps via vfs for non-Apple platforms. However, clang doesn't do anything similar for C-based targets, and so they fail to build.\n\nFor now, don't build with modules for any SPM C-based targets on non-Apple platforms.\n\n* Some problems are module cycles and headers being absorbed into unexpected modules. clang modules generally expect that OS/SDK headers are covered by module maps, and _not_ absorbed into whatever module happens to include them first.\n\nrdar://120716498","shortMessageHtmlLink":"Linux packages fail to build with LLVM 18 and Apple 2023 versions of …"}},{"before":"013a025b80b3ba90db10dcd3320cc249a31a3638","after":"2394eb7c9455d6e67e0719238e24252affaa4540","ref":"refs/heads/main","pushedAt":"2024-01-12T19:12:35.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ian-twilightcoder","name":"Ian Anderson","path":"/ian-twilightcoder","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14132058?s=80&v=4"},"commit":{"message":"Bump swift-tools-version to 5.9 (#7244)\n\nThis change only bumps tools version to 5.9 without making any other\r\nchanges, which allows us to isolate CI errors caused by this if such do\r\nhappen.","shortMessageHtmlLink":"Bump swift-tools-version to 5.9 (apple#7244)"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEMouobAA","startCursor":null,"endCursor":null}},"title":"Activity · ian-twilightcoder/swift-package-manager"}