选择Linux平台：
+## 最新版本 +-
+
-
+
Swiftly（推荐）
++ Swiftly 安装程序可以管理 Swift 及其依赖项。它支持在不同版本之间切换和下载更新。 +
+在终端中运行以下命令：
++curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \ +tar zxf swiftly-$(uname -m).tar.gz && \ +./swiftly init --quiet-shell-followup && \ +. ~/.local/share/swiftly/env.sh && \ +hash -r +许可证：Apache-2.0 | PGP：签名
+ 安装说明 +
+
-
+
-
+
容器
++ 如果您更喜欢容器化环境，可以下载官方容器镜像，用于在各种发行版上编译和运行 Swift。 +
+ Docker Hub + 安装说明 +
+
选择 Linux 平台：
diff --git a/_includes/install/_os_tabs.md b/_includes/install/_os_tabs.md
index 158e84c1a..70c5a4016 100644
--- a/_includes/install/_os_tabs.md
+++ b/_includes/install/_os_tabs.md
@@ -3,7 +3,7 @@
diff --git a/_posts/2022-07-14-vscode-extension.md b/_posts/2022-07-14-vscode-extension.md
index 1e8dbb2b3..319a5eb7e 100644
--- a/_posts/2022-07-14-vscode-extension.md
+++ b/_posts/2022-07-14-vscode-extension.md
@@ -6,7 +6,7 @@ title: Swift Extension for Visual Studio Code
author: adam-fowler
---
-As Swift is deployed across more platforms, it is important that Swift can be developed on more platforms as well. The [Swift Extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang) provides a cross-platform solution for Swift development supporting macOS, Linux, and Windows.
+As Swift is deployed across more platforms, it is important that Swift can be developed on more platforms as well. The [Swift Extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode) provides a cross-platform solution for Swift development supporting macOS, Linux, and Windows.
## Motivation
@@ -60,4 +60,4 @@ You can also use container support with the nightly Swift Docker images to test
The extension includes the core set of features we initially planned for, but we are not finished and will continue to expand on what we have. While much of the work initially was done by the SSWG, this is a community project and we are happy to involve anyone interested in contributing.
-If you feel something is missing or broken, please add an [Issue](https://github.com/swift-server/vscode-swift/issues). If you can contribute time to building new features or fixing bugs, please get in touch.
+If you feel something is missing or broken, please add an [Issue](https://github.com/swiftlang/vscode-swift/issues). If you can contribute time to building new features or fixing bugs, please get in touch.
diff --git a/_posts/2022-08-18-sswg-server-guides.md b/_posts/2022-08-18-sswg-server-guides.md
index 77b9590bd..bca398e24 100644
--- a/_posts/2022-08-18-sswg-server-guides.md
+++ b/_posts/2022-08-18-sswg-server-guides.md
@@ -10,7 +10,7 @@ The [Swift Server Workgroup](/sswg/) has maintained a set of open source guides
The guides cover a number of useful topics:
- * [Setting up your environment](/documentation/server/guides/setup-and-ide-alternatives.html)
+ * [Setting up your environment](/tools)
* [Building]({{site.url}}/documentation/server/guides/building.html) and [testing]({{site.url}}/documentation/server/guides/testing.html)
* [Profiling]({{site.url}}/documentation/server/guides/performance.html) and [deploying]({{site.url}}/documentation/server/guides/deployment.html) (including AWS, Digital Ocean, Heroku, and GCP)
* [Docker best practices]({{site.url}}/documentation/server/guides/packaging.html)
diff --git a/_posts/2023-08-17-sswg-update-2023.md b/_posts/2023-08-17-sswg-update-2023.md
index 585899c99..98147e8d7 100644
--- a/_posts/2023-08-17-sswg-update-2023.md
+++ b/_posts/2023-08-17-sswg-update-2023.md
@@ -42,7 +42,7 @@ We're also excited to see the introduction of [Custom Actor Executors](https://g
Notable highlights in tooling include:
-* The [Swift Extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang) reached version 1.0.0 and added new features like Swift Package plugin integration, Test Coverage and Test Explorer support, and more.
+* The [Swift Extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode) reached version 1.0.0 and added new features like Swift Package plugin integration, Test Coverage and Test Explorer support, and more.
* Swift Package plugins have seen adoption in many libraries, from formatters and linters, to code generators such as [SwiftProtobuf](https://github.com/apple/swift-protobuf/tree/main/Plugins/SwiftProtobufPlugin), [gRPC swift](https://github.com/grpc/grpc-swift/tree/main/Plugins/GRPCSwiftPlugin), [Smoke](https://github.com/amzn/smoke-framework-application-generate/tree/main/Plugins), and [Soto](https://soto.codes/2022/12/build-plugin-experiments.html).
* [Swiftly](https://github.com/swift-server/swiftly) is now available to try out and provides a simple way to install Swift on Linux and switch between versions.
diff --git a/_posts/2025-02-01-the-next-chapter-in-swift-build-technologies.md b/_posts/2025-02-01-the-next-chapter-in-swift-build-technologies.md
new file mode 100644
index 000000000..44e7ad016
--- /dev/null
+++ b/_posts/2025-02-01-the-next-chapter-in-swift-build-technologies.md
@@ -0,0 +1,33 @@
+---
+layout: post
+published: true
+date: 2025-02-01 6:00:00
+title: The Next Chapter in Swift Build Technologies
+author: [owen-voorhees]
+---
+
+Swift continues to grow in popularity as a cross-platform language supporting a wide variety of use cases, with support on a [variety of embedded devices](/blog/embedded-swift-examples/), form factors that encompass [wearables](https://developer.apple.com/documentation/watchos-apps/building_a_watchos_app) to [server](/documentation/server/), and a wide variety of [operating systems](/documentation/articles/static-linux-getting-started.html). As Swift expands, there’s value in investing in matching cross-platform build tools that provide a powerful, consistent, and flexible experience across the ecosystem.
+
+As a foundational step in this new chapter of Swift build technologies, today Apple is open sourcing [Swift Build](https://github.com/swiftlang/swift-build), a powerful and extensible build engine that provides a set of build rules for building Swift projects. Swift Build is the engine used by Xcode, which supports millions of apps in the App Store as well as the internal build process for Apple's own operating systems. The open source repository also includes support for targeting Linux and Windows.
+
+## Introducing Swift Build
+
+The primary responsibility of the build system is to transform user-authored inputs (such as a project description and source code) into output artifacts like command line tools, libraries, and applications. Build systems play an important role in providing a great developer experience, enabling higher level features which determine how users architect and work with their projects. Furthermore, the performance and reliability of a build system has a direct impact on developer productivity.
+
+Swift Build is an infrastructural component designed to plan and execute builds requested by a higher-level client like Swift Package Manager or Xcode. It builds on top of the existing [llbuild](https://github.com/swiftlang/swift-llbuild) project to add capabilities including:
+
+* Robust integration with the Swift compiler to reliably and efficiently coordinate the build of Swift projects
+* Support for a wide variety of product types including libraries, command line tools, and GUI applications with advanced build configuration options
+* Build graph optimizations that maximize parallelism when building Swift and C code
+
+## Roadmap for Swift Build
+
+Compared to the build engine in Xcode, the build engine in Swift Package Manager is fairly simple. On Apple platforms, having two different ways to build packages has also led to user confusion when the two implementations' behavior didn't match. Contributing Xcode's build engine to the Swift project and developing it in open source alongside the Swift compiler provides the tools necessary to address these problems and deliver a great builds experience to all Swift users. With this release, SwiftPM now has the opportunity to offer a unified build execution engine across all platforms. This change should be transparent to users and maintain full compatibility with all existing packages while delivering a consistent cross-platform experience. At the same time, it lays the foundation to enable new features and improvements across all platforms and tools, and unlocks new performance optimizations and developer-facing features. As a small first step towards this vision, today the team is submitting a pull request to begin the process of integrating support for Swift Build in SwiftPM as an alternate build engine. In the coming months, we'd like to collaborate with the community to complete the work of unifying build system integrations so users can benefit from future tooling improvements across all platforms and project models.
+
+We believe this is an important step in continuing to enable a healthy package ecosystem where developers can rely on a consistent, polished development experience — no matter what IDE they’re using or platform they’re targeting. We’ll be sharing more details about this work on the Swift forums, and we’re looking forward to hearing others’ feedback!
+
+## An invitation to participate
+
+We look forward to working with the community to continue evolving how we build Swift code. You can find the [`swift-build` repository](https://github.com/swiftlang/swift-build) in the Swift organization on GitHub, including a README and documentation describing how to build and contribute. Contributions via pull requests and issues are welcome, and we’d also love to solicit feedback and ideas for improvements on [the Swift forum](https://forums.swift.org/c/development/swift-build/).
+
+This is an exciting new chapter for Swift’s build system, and we’re looking forward to all the potential it opens for Swift!
diff --git a/_posts/2025-02-10-vscode-swift-2.md b/_posts/2025-02-10-vscode-swift-2.md
new file mode 100644
index 000000000..5d44fb45c
--- /dev/null
+++ b/_posts/2025-02-10-vscode-swift-2.md
@@ -0,0 +1,37 @@
+---
+layout: post
+published: true
+date: 2025-02-10 16:00:00
+title: Updating the Visual Studio Code extension for Swift
+author: [adam-ward]
+---
+
+Today, we are excited to announce a new version of the Swift extension for
+Visual Studio Code -- now [published to the extension
+marketplace](https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode)
+as an official supported release of the Swift team. The aim of this extension is
+to provide a high-quality, feature-complete extension that makes developing Swift
+applications on all platforms a seamless experience.
+
+
+
+As we continue to invest in Swift as a first-class language for cross-platform
+development, both Apple and the broader developer community are rapidly
+iterating on the VS Code extension to expand its capabilities for server and
+cloud, embedded, and Linux and Windows app development. The original extension
+was developed by members of the Swift Server Working Group, and with its broader
+scope, they have graciously supported this transition to the [GitHub /swiftlang
+organization](https://github.com/swiftlang) and the creation of a new publisher
+for the extension.
+
+For existing Swift developers using VS Code, the transition should be seamless:
+the old release should automatically install the new extension and disable
+itself, and moving forward all language features will be provided by the new
+extension. You’re welcome to uninstall the original extension, which has been
+renamed to reflect its deprecated status.
+
+Further details about the migration can be found on the [Swift
+Forums](https://forums.swift.org/t/vs-code-swift-extension-migration/77795). If
+you have any issues migrating, please [file an
+issue](https://github.com/swiftlang/vscode-swift/issues) or comment on the forum
+post.
\ No newline at end of file
diff --git a/_posts/2025-02-14-grpc-swift-2.md b/_posts/2025-02-14-grpc-swift-2.md
new file mode 100644
index 000000000..3ddc6c661
--- /dev/null
+++ b/_posts/2025-02-14-grpc-swift-2.md
@@ -0,0 +1,193 @@
+---
+layout: post
+published: true
+date: 2025-02-14 10:00:00
+title: Introducing gRPC Swift 2
+author: [george-barnett, gus-cairo]
+---
+
+Say hello to gRPC Swift 2: a major update that brings first-class concurrency
+support and more expressive APIs for a seamless developer experience.
+
+Inconsistent and poorly documented service APIs create integration headaches for
+developers. gRPC is a modern, high-performance framework for building service
+APIs, enabling efficient communication between systems over a network.
+
+Since services may be written with a different language than their clients, most
+gRPC services use [Protocol Buffers](https://protobuf.dev/) (or “protobufs”) to
+define their APIs and the messages exchanged between clients and servers.
+Service contracts are defined in a neutral, cross-platform format using `.proto`
+files. This is the foundation of your service, not an artefact of its
+implementation. And thanks to the format’s efficient binary serialization, these
+messages are typically smaller and faster to process than other standard formats
+like JSON.
+
+gRPC Swift is one of a family of similar tools that use the Protocol Buffers
+contract to generate code in the language you’re working with, making it easy to
+build clients and servers that adhere to your service contract. And the new gRPC
+Swift 2 offers an idiomatic, cross-platform, performant and feature-rich library
+for building highly-scalable services.
+
+This release is a major update that takes advantage of many modern Swift
+features for cross-platform services development. When gRPC Swift was first
+developed back in 2018, Swift had not yet introduced concurrency features like
+[async/await](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency/),
+so it was instead based on SwiftNIO’s event-driven concurrency model. For
+developers unfamiliar with these concepts, the prior version of gRPC Swift
+presented a steep learning curve. Now that Swift’s modern concurrency model is
+fully established, we seized the opportunity to rethink gRPC Swift for today’s
+Swift, incorporating lessons learned from our years of use at Apple for building
+internet-scale services.
+
+## Highlights
+
+* Modern, flexible, and easy-to-use APIs with idiomatic generated code.
+* Full support for building services and clients on Linux and Apple platforms.
+* Pluggable transports including a high-performance HTTP/2 transport built on
+ top of [SwiftNIO](https://github.com/apple/swift-nio), and an in-process
+ transport which is great for testing.
+* Smart client features like client-side load balancing, a pluggable name
+ resolution mechanism and automatic retries.
+* A flexible interceptor layer allowing you to implement cross-cutting logic
+ like authentication, logging, and metrics.
+
+## Hello, swift.org!
+
+Consider the canonical "hello world" service with a single API which returns a
+greeting. You might define it like this in a `.proto` file:
+
+```proto
+syntax = "proto3";
+
+service GreetingService {
+ // Returns a personalized greeting.
+ rpc SayHello(SayHelloRequest) returns (SayHelloResponse);
+}
+
+message SayHelloRequest {
+ // The name of the person to greet.
+ string name = 1;
+}
+
+message SayHelloResponse {
+ // The personalized greeting message.
+ string message = 1;
+}
+```
+
+gRPC can be configured to generate:
+
+* Service code so you can implement the business logic.
+* Client code to make requests against the service.
+
+Code for messages is generated by
+[SwiftProtobuf](https://github.com/apple/swift-protobuf/) and used in
+conjunction with the generated gRPC code.
+
+### Generated Service Code
+
+The generated code includes a Swift protocol describing the requirements of the
+service with one method for each `rpc` in the service definition. To implement
+the business logic of your service just implement one of the service protocols.
+The example below uses the `SimpleServiceProtocol` which is the highest level
+API. If you need more flexibility you can use the `ServiceProtocol` or
+`StreamingServiceProtocol` which trade off conciseness for flexibility.
+
+To start the service you need to create a server configured to use a transport
+and an instance of your service:
+
+```swift
+import GRPCCore
+import GRPCNIOTransportHTTP2
+
+struct Greeter: GreetingService.SimpleServiceProtocol {
+ func sayHello(
+ request: SayHelloRequest,
+ context: ServerContext
+ ) async throws -> SayHelloResponse {
+ return SayHelloResponse.with {
+ $0.message = "Hello, \(request.name)!"
+ }
+ }
+}
+
+@main
+struct GreeterServer {
+ static func main() async throws {
+ // Create a plaintext server using the SwiftNIO based HTTP/2 transport
+ // listening on 128.0.0.1:8080.
+ let server = GRPCServer(
+ transport: .http2NIOPosix(
+ address: .ipv4(host: "127.0.0.1", port: 8080),
+ transportSecurity: .plaintext
+ ),
+ services: [Greeter()]
+ )
+
+ // Start serving indefinitely.
+ try await server.serve()
+ }
+}
+```
+
+### Generated Client Code
+
+gRPC generates an idiomatic client for you, simplifying service calls. To use
+it, first create a raw client and wrap it with the generated client specific to
+your service. This generated client provides a type-safe way for you to easily
+interact with your service.
+
+```swift
+import GRPCCore
+import GRPCNIOTransportHTTP2
+
+@main
+struct SayHello {
+ static func main() async throws {
+ // Create a plaintext client using the SwiftNIO based HTTP/2 transport
+ // connecting to a service listening on 128.0.0.1:8080.
+ try await withGRPCClient(
+ transport: .http2NIOPosix(
+ target: .dns(host: "127.0.0.1", port: 8080),
+ transportSecurity: .plaintext
+ )
+ ) { client in
+ let greeter = GreetingService.Client(wrapping: client)
+ let greeting = try await greeter.sayHello(.with { $0.name = "swift.org" })
+ print(greeting.message)
+ }
+ }
+}
+```
+
+## Package Ecosystem
+
+gRPC Swift 2 was designed with flexibility in mind. It's distributed as a
+collection of packages, allowing you to pick and choose the components which
+best suit your needs. These features are provided by the following packages:
+
+* [grpc/grpc-swift](https://github.com/grpc/grpc-swift) provides runtime
+ abstractions and types.
+* [grpc/grpc-swift-nio-transport](https://github.com/grpc/grpc-swift-nio-transport)
+ implements client and server transports using HTTP/2 and is built on top of
+ SwiftNIO.
+* [grpc/grpc-swift-protobuf](https://github.com/grpc/grpc-swift-protobuf)
+ integrates with [SwiftProtobuf](https://github.com/apple/swift-protobuf/) to
+ provide a code generator for services defined in `.proto` files.
+* [grpc/grpc-swift-extras](https://github.com/grpc/grpc-swift-extras) includes
+ common gRPC add-ons, like the reflection and health services, integrations
+ with [Swift Service
+ Lifecycle](https://github.com/swift-server/swift-service-lifecycle), and
+ interceptors to trace RPCs using [OpenTelemetry](https://opentelemetry.io/).
+
+## Next Steps
+
+To get started with gRPC Swift 2 check out the [tutorials and
+documentation](https://swiftpackageindex.com/grpc/grpc-swift/documentation)
+which are hosted on the Swift Package Index, or try out one of the examples in
+the [grpc/grpc-swift](https://github.com/grpc/grpc-swift) repository.
+
+If you have feature requests, want to report a bug, or would like to contribute
+to the project then please reach out to us on
+[GitHub](https://github.com/grpc/grpc-swift) or join us on the [Swift
+forums](https://forums.swift.org/c/related-projects/grpc-swift/). Let’s connect!
diff --git a/_posts/2025-02-21-how-swifts-server-support-powers-things-cloud.md b/_posts/2025-02-21-how-swifts-server-support-powers-things-cloud.md
new file mode 100644
index 000000000..162e12183
--- /dev/null
+++ b/_posts/2025-02-21-how-swifts-server-support-powers-things-cloud.md
@@ -0,0 +1,113 @@
+---
+layout: post
+published: true
+date: 2025-02-21 10:00:00
+title: How Swift's server support powers Things Cloud
+author: [vrylko, wjainek]
+---
+
+You might be familiar with [Things](https://culturedcode.com/things/), a delightful personal task manager that has won two Apple Design Awards and is available across Apple devices including iPhone, iPad, Mac, Apple Watch, and Apple Vision Pro. At Cultured Code, the team behind Things, we care about a great user experience across every aspect of the product. This extends to our server back end, and after a rewrite our Things Cloud service has transitioned entirely to Swift. Over the past year in production, Swift has consistently proven to be reliable, performant, and remarkably well-suited for our server-side need.
+
+
+
+[Things Cloud](https://culturedcode.com/things/cloud/) serves as the backbone of the app’s experience, silently synchronizing to-dos across devices. The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind.
+
+` to the list.
diff --git a/documentation/cxx-interop/status/index.md b/documentation/cxx-interop/status/index.md
index a551c5030..23b8fbd93 100644
--- a/documentation/cxx-interop/status/index.md
+++ b/documentation/cxx-interop/status/index.md
@@ -79,10 +79,20 @@ code for a specific deployment platform:
| **Ubuntu, CentOS, Amazon Linux** | libstdc++ |
| **Windows** | Microsoft C++ Standard Library (msvcprt) |
+Swift also supports selecting libc++ when building on certain Linux
+distributions by passing `-Xcc -stdlib=libc++` flags. On those distributions,
+libc++ needs to be installed from a system package manager, e.g. apt or yum.
+This compatibility matrix shows the versions of libc++ that are supported by
+Swift when building for various Linux versions:
+
+| Linux version running Swift application | Supported libc++ package |
+|-----------------------------------------|--------------------------|
+| Ubuntu 22.04 | libc++-15-dev |
+| Ubuntu 24.04 | libc++-18-dev |
+
Swift does not currently support selecting an alternative standard library for
-platforms that support alternative standard libraries. For example, you can't use
-libc++ when building Swift code for Ubuntu, even though libc++ can be used when
-building C++ code for Ubuntu.
+other platforms. For example, you can't use libc++ when building Swift code for
+Windows, even though libc++ can be used when building C++ code for Windows.
Mixed Swift and C++ code must use
the same C++ standard library.
@@ -186,10 +196,11 @@ The following C++ standard library types are supported in Swift:
- Specializations of `std::set`, `std::multiset` and `std::unordered_set`
- Specializations of `std::optional`
- Specializations of `std::shared_ptr`
+- Specializations of `std::unique_ptr`
- Specializations of `std::array`
-Other standard library types, like `std::unique_ptr`, `std::function` and
-`std::variant` are not yet supported in Swift.
+Other standard library types, like `std::function` and `std::variant`, are not
+yet supported in Swift.
### Other C++ Features Handled by Swift
@@ -219,16 +230,14 @@ header.
### Swift Structures Supported by C++
-Swift can generate C++ representation for most top-level Swift structures. The
-following Swift structures are not yet supported:
+Swift can generate C++ representation for most Swift structures. The following
+Swift structures are not yet supported:
- Zero-sized structures that don't have any stored properties
- Non-copyable structures
- Generic structures with generic constraints, or with more than three generic
parameters, or that have variadic generics
-Swift currently does not expose nested structures to C++.
-
### Swift Classes and Actors Supported by C++
Swift can generate C++ representation for most top-level Swift classes and
@@ -237,8 +246,6 @@ following Swift classes are not yet supported:
- Generic classes and actors
-Swift currently does not expose nested classes and actors to C++.
-
### Swift Enumerations Supported by C++
Swift can generate C++ representation for most top-level Swift enumerations
@@ -341,6 +348,7 @@ standard library that can be represented in C++:
| `CBool` | `bool` |
| `CChar` | `char` |
| `CWideChar` | `wchar_t` |
+| `CChar8` | `char8_t` |
| `CChar16` | `char16_t` |
| `CChar32` | `char32_t` |
| `CSignedChar` | `signed char` |
@@ -359,7 +367,7 @@ standard library that can be represented in C++:
## Constraints and Limitations
Swift has some known limitations related to C++ interoperability support.
-They're currently [listed on GitHub](https://github.com/swiftlang/swift/issues/66159).
+They are currently [tracked on GitHub](https://github.com/swiftlang/swift/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22c%2B%2B%20interop%22).
### Swift Package Manager Constraints
diff --git a/documentation/monthly-non-darwin-release/index.md b/documentation/monthly-non-darwin-release/index.md
new file mode 100644
index 000000000..35b5ceecb
--- /dev/null
+++ b/documentation/monthly-non-darwin-release/index.md
@@ -0,0 +1,38 @@
+---
+redirect_from: "/monthly-non-darwin-release/"
+layout: page
+title: Monthly Non-Darwin Swift Releases
+---
+
+The release manager will announce the merge window for each monthly release. This merge window will remain open for about three weeks, after which it will close. Immediately following the merge window close, release managers have one week to finalize the release which will then be published on swift.org. All the relevant dates will be communicated upfront in the announcement on Swift Forums.
+
+Once the merge window is open, everybody can open a pull request against the release branch announced in the forum post. To keep the process smooth and lightweight, the release manager will only consider pull requests that
+
+* are bug fixes,
+* have already been merged to `main`,
+* pass all the unit tests on release branch, and
+* contain at least one unit test exercising the changed code.
+
+We expect most bug fixes to be small corrections, so creating the pull request might be a matter of creating a branch followed by `git cherry-pick -x FIX-COMMIT-FROM-MAIN-SHA`. We do realize not all backports will be a conflict-free cherry picks but we hope the community works together to deliver the most pressing bug fixes in a timely manner. The changes for the dot release must be only focus on non-darwin platforms only.
+
+
+## Pull Requests for Release Branch
+
+In order for a pull request to be considered for inclusion in the release branch after it has been cut, the pull request must have:
+
+
+* A title starting with a designation containing the release version number of the target branch.
+* [This](https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1) form filled out in its description. An item that is not applicable may be left blank or completed with an indication thereof, but must not be omitted altogether.
+
+To switch to this template when drafting a pull request in a [swiftlang](https://github.com/swiftlang) repository in a browser, append the `template=release.md` query parameter to the current URL and refresh. For example:
+
+```
+-https://github.com/swiftlang/swift/compare/main...my-branch?quick_pull=1
++https://github.com/swiftlang/swift/compare/main...my-branch?quick_pull=1&template=release.md
+```
+
+**All changes** going on the release branch **must go through pull requests** that are accepted by the corresponding release manager.
+
+If you think there's an important bug fix that should go into the next dot release, but you don’t have the ability to fix it in time, please use the Swift Forums to rally for help. The Swift community includes a bunch of folks ready to assist, and sometimes raising attention on a bug is all that’s needed to get it fixed. As always, please remember that most of the community is not working on Swift full time, so be kind.
+
+Similarly, if you have opened a pull request, you might want to assign the release manager on the Github pull request so they can have a look straight away. The release managers will merge patches throughout the whole merge window. Once the merge window closes however, no further pull requests will be considered until the next merge window opens.
diff --git a/documentation/server/guides/libraries/log-levels.md b/documentation/server/guides/libraries/log-levels.md
index dc443102b..a361cffd8 100644
--- a/documentation/server/guides/libraries/log-levels.md
+++ b/documentation/server/guides/libraries/log-levels.md
@@ -22,7 +22,7 @@ SwiftLog defines the following 7 log levels via the [`Logger.Level` enum](https:
* `error`
* `critical`
-Out of those, only levels _less severe than_ info (exclusively) are generally okay to be used by libraries.
+Out of those, only levels _less severe than_ `info` (exclusively) are generally okay to be used by libraries: `debug` and `trace`.
In the following section we'll explore how to use them in practice.
@@ -68,26 +68,26 @@ Some libraries and situations may not be entirely clear with regard to what log
### Log levels to avoid
-All these rules are only _general_ guidelines, and as such may have exceptions. Consider the following examples and rationale for why logging at high log levels by a library may not be desirable:
+All these rules are only _general_ guidelines, and as such may have exceptions. Consider the following examples and rationale for why logging at severe log levels by a library may not be desirable:
It is generally _not acceptable_ for a service client (for example, an http client) to log an `error` when a request has failed. End-users may be using the client to probe if an endpoint is even responsive or not, and a failure to respond may be _expected_ behavior. Logging errors would only confuse and pollute their logs.
Instead, libraries should either `throw`, or return an `Error` value that users of the library will have enough knowledge about if they should log or ignore it.
-It is even less acceptable for a library to log any successful operations. This leads to flooding server side systems, especially if, for example, one were to log every successfully handled request. In a server side application, this can easily flood and overwhelm logging systems when deployed to production where many end users are connected to the same server. Such issues are rarely found in development time, because of only a single peer requesting things from the service-under-test.
+It is even less acceptable for a library to log any successful operations at a more severe log level than `debug`. This leads to flooding server side systems, especially if, for example, one were to log every successfully handled request. In a server side application, this can easily flood and overwhelm logging systems when deployed to production where many end users are connected to the same server. Such issues are rarely found in development time, because of only a single peer requesting things from the service-under-test.
#### Examples (of things to avoid)
-Avoid using `info` or any higher log level for:
+Avoid using `info` or any more severe log level for:
-- "Normal operation" of the library, that is there is no need to log on info level "accepted a request" as this is the normal operation of a web service.
+- "Normal operation" of the library, there is no need to log on info level "accepted a request" as this is the normal operation of a web service.
Avoid using `error` or `warning`:
- To report errors which the end-user of the library has the means of logging themselves. For example, if a database driver fails to fetch all rows of a query, it should not log an error or warning, but instead return or throw an error on the stream of values (or function, async function, or even the async sequence) that was providing the returned values.
- Since the end-user is consuming these values, and has a mean of reporting (or swallowing) this error, the library should not log anything on their behalf.
- Never report as warnings which is merely an information. For example. "weird header detected" may look like a good idea to log as a warning at first sight, however if the "weird header" is simply a misconfigured client (or just a "weird browser") you may be accidentally completely flooding an end-users logs with these "weird header" warnings (!)
- - Only log warnings about actionable things which the end-user of your library can do something about. Using the "weird header detected" log statement as an example: it would not be a good candidate to log as a warning because the server developer has no way to fix the users of their service to stop sending weird headers, so the server should not be logging this information as a warning.
+ - Only log warnings about actionable things which the end-user of your library can do something about. Using the "weird header detected" log statement as an example: it would not be a good candidate to log as a warning because the server developer has no way to fix the users of their service to stop sending weird headers, so the server should not be logging this information as a warning. It might still be appropriate to log it at a `debug` level, however.
- It may be tempting to implement a "log as warning only once" technique for per-request style situations which may be almost important enough to be a warning, but should not be logged repeatedly after all. Authors may think of smart techniques to log a warning only once per "weird header discovered" and later on log the same issue on a different level, such as trace... Such techniques result in confusing hard to debug logs, where developers of a system unaware of the stateful nature of the logging would be left confused when trying to reproduce the issue.
- For example, if a developer spots such a warning in a production system, they may attempt to reproduce it — thinking that it only happens in the production environment. However, if the logging system's log level choice is _stateful_ they may actually be successfully reproducing the issue but never seeing it manifest. For this, and related performance reasons (as implementing "only once per X" implies growing storage and per-request additional checking requirements), it is not recommended to apply this pattern.
@@ -97,6 +97,29 @@ Exceptions to the "avoid logging warnings" rule:
- Consider offering an API that would collect errors at runtime, and then you can avoid logging errors manually. This can often take the form of a customizable "on error" hook that the library accepts when constructing the scheduled job. If the handler is not customized, we can log the errors, but if it was, it again is up to the end-user of the library to decide what to do with them.
- An exception to the "log a warning only once" rule is when things do not happen very frequently. For example, if a library is warning about an outdated license or something similar during _its initialization_ this isn't necessarily a bad idea. After all, we'd rather see this warning once during initialization rather during every request made to the library. Use your best judgement and consider the developers using your library when designing how often and where from to log such information.
+### Avoid mutating the log level or log handler
+
+Library code should emit informative logs, and let the current `Logger`'s `LogHandler` handle filtering and actually exporting the logs to a backend system. The executable target that links the library is responsible for configuring `LogHandler`'s and log levels.
+
+It is an anti-pattern for a library to mutate the log level or `LogHandler` of a `Logger`, so avoid code like this:
+
+```swift
+// ⚠️ Avoid mutating log levels in libraries
+var localLogger = logger
+localLogger.logLevel = .warning
+// ...
+```
+
+And like this:
+
+```swift
+// ⚠️ Avoid creating loggers with a log handler factory in libraries
+let localLogger = Logger(label: "Local", factory: ...)
+// ...
+```
+
+Any such code should be included in the executable target instead.
+
### Suggested logging style
While libraries are free to use whichever logging message style they choose, here are some best practices to follow if you want users of your libraries to *love* the logs your library produces.
diff --git a/documentation/server/guides/memory-leaks-and-usage.md b/documentation/server/guides/memory-leaks-and-usage.md
index b4cd22bd5..14f7d866a 100644
--- a/documentation/server/guides/memory-leaks-and-usage.md
+++ b/documentation/server/guides/memory-leaks-and-usage.md
@@ -4,50 +4,50 @@ layout: page
title: 调试内存泄漏
---
-# 概述
+# Overview
-调试内存泄漏和使用情况有助于识别和解决应用程序中与内存管理相关的问题。内存泄漏发生在内存被分配但未正确释放时，导致内存使用量随时间逐渐增加。这会严重影响应用程序的性能和稳定性。
+Debugging memory leaks and usage helps you identify and resolve issues related to memory management in an application. Memory leaks occur when memory is allocated but not properly deallocated, leading to a gradual increase in memory usage over time. This can severely impact an application's performance and stability.
-然而，需要注意的是，内存使用量随时间逐渐增加并不总是表示存在泄漏。相反，这可能是应用程序的内存特征。例如，当应用程序的缓存随时间逐渐填满时，它会显示出相同的内存使用量逐渐增加。因此，配置缓存使其不会超出指定限制将导致内存使用量趋于平稳。此外，由于性能或其他原因，分配器库并不总是立即将内存反馈给系统。但随着时间的推移，它会稳定下来。
+It’s important to note, however, that a gradual increase in memory usage over time doesn’t always indicate a leak. Instead, it may be the memory profile of the application. For example, when an application’s cache gradually fills over time it shows the same gradual increase in memory. Accordingly, configuring the cache so it doesn’t expand beyond a designated limit will cause the memory usage to plateau. Additionally, allocator libraries don't always immediately return memory feedback to the system due to performance or other reasons. But it will stabilize over time.
-## 工具和技术
+## Tools and techniques
-在 macOS 和 Linux 环境中调试 Swift 的内存泄漏可以使用不同的工具和技术，每种工具和技术都有其独特的优势和可用性。
+Debugging memory leaks in Swift on macOS and Linux environments can be done using different tools and techniques, each with distinct strengths and usability.
-### 基本故障排除包括：
+### Basic troubleshooting includes:
-* 使用分析工具。
-* 审查代码并识别潜在的泄漏。
-* 启用调试内存分配功能。
+* Using profiling tools.
+* Reviewing code and identifying potential leaks.
+* Enabling debug memory allocation features.
-**1. 使用分析工具** 由各自的操作系统和开发环境提供，用于识别和分析内存使用情况。
+**1. Using profiling tools** provided by the respective operating systems and development environments to identify and analyze memory usage.
-*对于 macOS*： [Memory Graph Debugger](https://developer.apple.com/documentation/xcode/gathering-information-about-memory-use#Inspect-the-debug-memory-graph) 和这个 [Detect and diagnose memory issues](https://developer.apple.com/videos/play/wwdc2021/10180/) 视频非常有帮助。你还可以使用 [Xcode Instruments](https://help.apple.com/instruments/mac/10.0/#/dev022f987b) 工具，其中包括 [Allocations instrument](https://developer.apple.com/documentation/xcode/gathering-information-about-memory-use#Profile-your-app-using-the-Allocations-instrument) 来跟踪 Swift 代码中的内存分配和释放。
+*For macOS*: [Memory Graph Debugger](https://developer.apple.com/documentation/xcode/gathering-information-about-memory-use#Inspect-the-debug-memory-graph) and this [Detect and diagnose memory issues](https://developer.apple.com/videos/play/wwdc2021/10180/) video are helpful. You can also use the [Xcode Instruments](https://help.apple.com/instruments/mac/10.0/#/dev022f987b) tool for various profiling instruments including the [Allocations instrument](https://developer.apple.com/documentation/xcode/gathering-information-about-memory-use#Profile-your-app-using-the-Allocations-instrument) to track memory allocation and deallocation in your Swift code.
+
+*For Linux*: You can use tools like [Valgrind](https://valgrind.org/) or [Heaptrack](https://github.com/KDE/heaptrack) to profile your application as shown in the examples below. Although these tools are primarily used for C/C++ code, they can also work with Swift.
-*对于 Linux*：你可以使用 [Valgrind](https://valgrind.org/) 或 [Heaptrack](https://github.com/KDE/heaptrack) 等工具来分析你的应用程序，如下面的示例所示。虽然这些工具主要用于 C/C++ 代码，但它们也可以用于 Swift。
+**2. Reviewing code and identifying potential leaks** to examine your code for any potential areas where memory leaks may occur. Common sources of leaks include retained references or unbalanced retain-release cycles, which rarely apply to Swift since it performs [automatic reference counting (ARC)](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/).
-**2. 审查代码并识别潜在的泄漏** 以检查代码中可能发生内存泄漏的任何潜在区域。常见的泄漏来源包括保留的引用或不平衡的保留-释放周期，这在 Swift 中很少适用，因为它执行 [automatic reference counting (ARC)](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/)。
+> Note: Memory leaks can occur in Swift if there are substantial reference cycles between objects that involve closures or if objects hold references to external resources that are not released properly. However, the likelihood of such issues is significantly reduced through the automatic memory management's ability to add and remove references, making sources of leaks like retained references and unbalanced retain-release cycles less common in Swift code.
-> 注意：如果对象之间存在涉及闭包的实质性引用循环，或者对象持有未正确释放的外部资源的引用，Swift 中可能会发生内存泄漏。然而，通过自动内存管理添加和删除引用的能力，显著减少了保留引用和不平衡保留-释放周期等泄漏来源在 Swift 代码中出现的可能性。
+**3. Enabling debug memory allocation features** allows you to get additional information about objects and their memory allocations.
+
+*On macOS*: You can enable Zombie Objects using Xcode or use [MallocStackLogging](https://developer.apple.com/videos/play/wwdc2022/10106/) to detect over-released or accessed deallocated objects.
+
+To enable Zombie Objects:
+1. Open your Xcode project.
+2. Go to the **Edit Scheme** menu by clicking on the scheme dropdown in the toolbar.
+3. In the scheme editor window, select the **Run** tab.
+4. Choose the **Diagnostics** tab.
+5. Under **Memory Management**, check the box next to **Enable Zombie Objects**.
+
+*在 Linux 上*：Swift 内置了 LeakSanitizer 支持，可以通过地址消毒器（Address Sanitizer）启用。更多信息，请阅读[使用 LeakSanitizer 调试内存泄漏](#debugging-leaks-with-leaksanitizer)部分。
-**3. 启用调试内存分配功能** 允许您获取有关对象及其内存分配的附加信息。
+## Troubleshooting
-*在 macOS 上*：您可以使用 Xcode 启用 Zombie Objects 或使用 [MallocStackLogging](https://developer.apple.com/videos/play/wwdc2022/10106/) 来检测过度释放或访问已释放的对象。
+This section aims to provide you with helpful server-side troubleshooting techniques to debug leaks and usage using **Valgrind**, **LeakSanitizer**, and **Heaptrack**.
-启用 Zombie Objects 的步骤：
-1. 打开您的 Xcode 项目。
-2. 通过点击工具栏中的方案下拉菜单进入 **Edit Scheme** 菜单。
-3. 在方案编辑器窗口中，选择 **Run** 选项卡。
-4. 选择 **Diagnostics** 选项卡。
-5. 在 **Memory Management** 下，勾选 **Enable Zombie Objects** 旁边的框。
-
-*在 Linux 上*：Swift 内置了 LeakSanitizer 支持，可以使用 `-sanitize=leak` 编译器标志启用。
-
-## 故障排除
-
-本节旨在为您提供有用的服务器端故障排除技术，以使用 **Valgrind**、**LeakSanitizer** 和 **Heaptrack** 调试内存泄漏和使用情况。
-
-以下 **示例程序** 会泄漏内存。我们仅将其用作示例来说明下面提到的各种故障排除方法。
+The following **example program** leaks memory. We are using it as an *example only* to illustrate the various troubleshooting methods mentioned below.
```
public class MemoryLeaker {
diff --git a/documentation/server/guides/setup-and-ide-alternatives.md b/documentation/server/guides/setup-and-ide-alternatives.md
deleted file mode 100644
index 1bb2953cc..000000000
--- a/documentation/server/guides/setup-and-ide-alternatives.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-redirect_from: "server/guides/setup-and-ide-alternatives"
-layout: page
-title: Installing Swift and using with IDEs
----
-
-## Installing Swift
-
-The [supported platforms](/platform-support/) for running Swift on the server and the [ready-built tools packages](/download/) are all hosted here on swift.org together with installation instructions. There's also the [language reference documentation](/documentation/) section for viewing more information about Swift.
-
-## IDEs/Editors with Swift Support
-
-A number of editors you may already be familiar with have support for writing Swift code. Here we provide a non-exhaustive list of such editors and relevant plugins/extensions, sorted alphabetically.
-
-* [Atom IDE support](https://atom.io/packages/ide-swift)
- * [Atomic Blonde](https://atom.io/packages/atomic-blonde) a SourceKit based syntax highlighter for Atom.
-
-* [Emacs plugin](https://github.com/swift-emacs/swift-mode)
-
-* [VIM plugin](https://github.com/keith/swift.vim)
-
-* [Visual Studio Code](https://code.visualstudio.com)
- * [Swift for Visual Studio Code extension](https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang)
-
-* [Xcode](https://developer.apple.com/xcode/ide/)
-
-## Language Server Protocol (LSP) Support
-
-The [SourceKit-LSP project](https://github.com/swiftlang/sourcekit-lsp) provides a Swift implementation of the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/), which provides features such as code completion and jump-to-definition in supported editors.
-
-The project has both an [extensive list of editors that support it](https://github.com/swiftlang/sourcekit-lsp/tree/main/Editors) and setup instructions for those editors, including many of those listed above.
-
-_Do you know about another IDE or IDE plugin that is missing? Please submit a PR to add them here!_
diff --git a/getting-started/_use-cases.md b/getting-started/_use-cases.md
index fd2f167a0..fd1dfe79a 100644
--- a/getting-started/_use-cases.md
+++ b/getting-started/_use-cases.md
@@ -70,4 +70,4 @@
---
-需要语言参考？[Swift 编程语言 (TSPL)](https://doc.swiftgg.team/documentation/the-swift-programming-language/) 书籍提供[多种语言版本](/documentation/tspl/#translations)。
+需要语言参考？[Swift 编程语言 (TSPL)](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/) 书籍提供[多种语言版本](/documentation/tspl/#translations)。
diff --git a/getting-started/embedded-swift/index.md b/getting-started/embedded-swift/index.md
index 3f7b12b5e..15272f475 100644
--- a/getting-started/embedded-swift/index.md
+++ b/getting-started/embedded-swift/index.md
@@ -9,7 +9,7 @@ title: 为微控制器构建嵌入式应用
## 安装 Swift
-如果你还没有安装 Swift,请先[安装 Swift](https://swift.swiftgg.team/install)。由于嵌入式 Swift 目前还处于实验阶段,仅在预览工具链中提供,因此请确保安装"开发快照"工具链(main),而不是发布工具链(6.0)。如果你使用的是 macOS 机器,需要确保已安装的工具链被选为活动状态,例如通过导出 `TOOLCHAINS` 环境变量:
+如果您尚未安装 Swift，请[先安装它](https://www.swift.org/install)。由于嵌入式 Swift 仍处于实验阶段，且仅在预览工具链中可用，请确保安装"开发快照"工具链（main），而不是发布工具链（6.0）。如果您使用的是 macOS 设备，需要确保已安装并选择了 Xcode，可以通过运行 `xcode-select -p` 并验证它指向 Xcode 安装路径来确认。接下来，确保将已安装的开发快照选择为活动工具链，例如通过导出 `TOOLCHAINS` 环境变量：
```shell
$ export TOOLCHAINS=org.swift.59202405011a
diff --git a/gsoc2024/index.md b/gsoc2024/index.md
index 210134949..8c1bf3901 100644
--- a/gsoc2024/index.md
+++ b/gsoc2024/index.md
@@ -147,7 +147,7 @@ Provide all keyword or punctuator completions that are valid at a certain positi
Swift Macros allow the generation of source code at compile time. While this provides concise code and avoids repetition of common paradigms, understanding the source code can become harder if it is unknown what the macro expands to.
-Visual Studio Code using the [Swift Extension](https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang) currently has limited ability to show the code generated by a macro by invoking a code action that replaces the macro by its generated code inside the current source file.
+Visual Studio Code using the [Swift Extension](https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode) currently has limited ability to show the code generated by a macro by invoking a code action that replaces the macro by its generated code inside the current source file.
The project's goal is to implement a code action to show the macro-generated code without modifying the current source file. This includes the implementation of a request in [sourcekit-lsp](https://github.com/swiftlang/sourcekit-lsp) to compute the contents of the macro expansion and support in the Visual Studio Swift Extension to display that content. Some initial discussion of how the design could look like can be found in [this thread](https://github.com/swiftlang/sourcekit-lsp/pull/892#discussion_r1358428808).
diff --git a/gsoc2025/index.md b/gsoc2025/index.md
new file mode 100644
index 000000000..b75931672
--- /dev/null
+++ b/gsoc2025/index.md
@@ -0,0 +1,448 @@
+---
+layout: page
+title: Project Ideas for GSoC 2025
+---
+
+This page contains a non-exhaustive list of potential project ideas that we are keen to develop during [Google Summer of Code 2025](https://summerofcode.withgoogle.com/). If you would like to apply to GSoC as a contributor, please follow these steps to get started:
+
+1. Read through this page and the Google Summer of Code guides,
+2. Identify, or come up with your own project ideas you find interesting.
+3. Check out the [Development forum](https://forums.swift.org/c/development/gsoc/98) to connect with potential mentors.
+- Feel free to mention the project mentors on the forums, when starting a thread about your interest in participating in a specific project they are offering to mentor.
+
+When posting on the forums about GSoC this year, please use the [`gsoc-2025` tag](https://forums.swift.org/tag/gsoc-2025), so it is easy to identify.
+
+## Tips for contacting mentors
+
+The Swift forums are powered by discourse, a discussion forums platform with spam avoidance mechanisms built-in. If this is your first time joining the forums, you _may_ not be able to send mentors a direct message, as this requires a minimum amount of prior participation before the "send private message" feature is automatically enabled.
+
+To start things off, we recommend starting a new thread or joining an existing discussion about the project you are interested in on the dedicated [GSoC forums category](https://forums.swift.org/c/development/gsoc/98). You should also _tag_ your thread with the `gsoc-2025` tag. It is best if you start a thread after having explored the topic a little bit already, and come up with specific questions about parts of the project you are not sure about. For example, you may have tried to build the project, but not sure where a functionality would be implemented; or you may not be sure about the scope of the project.
+
+Please use the forums to tag and communicate with the project's mentor to figure out the details of the project, such that when it comes to writing the official proposal plan, and submitting it on the Summer of Code website, you have a firm understanding of the project and can write a good, detailed proposal (see next section about hints on that).
+
+If you would like to reach out to a mentor privately rather than making a public forum post, and the forums are not allowing you to send private messages yet, please reach out to Konrad Malawski at `ktoso AT apple.com` directly via email with the `[gsoc2025]` tag in the email subject and describe the project you would like to work on. We will route you to the appropriate mentor. In general, public communications on the forums are preferred though, as this is closer to the normal open-source way of getting things done in the Swift project.
+
+## Writing a proposal
+
+Getting familiar with the codebase you are interested in working on during GSoC helps to write a good proposal because it helps you get a better understanding of how everything works and how you might best approach the project you are interested in. How you want to do that is really up to you and your style of learning. You could just clone the repository, read through the source code and follow the execution path of a test case by setting a breakpoint and stepping through the different instructions, read the available documentation or try to fix a simple bug in the codebase. The latter is how many open-source contributors got started, but it’s really up to you. If you do want to go and fix a simple bug, our repositories contain a label “good first issue” that marks issues that should be easy to fix and doable by newcomers to the project.
+
+When it comes to writing the proposal, the [Google Summer of Code Guide](https://google.github.io/gsocguides/student/writing-a-proposal) contains general, good advice.
+
+The best proposals include a detailed timeline, specific milestones and goals as well as an outline the technical challenges you foresee. It is best if you engage with your potential project mentor on the forums before contriburing, and have them clarify the goals and steps that they think are necessary for the project to be successful. Your proposal should have a clear goal, which can be successfully achieved as part of the weeks you'll be working it. Provide details about your approach, significant milestones you wish to achieve, and clarify with your potential mentor if they agree those seem reasonable. The time before proposal submissions is there for you to reach out and polish your proposal, so make sure you use it well! Good luck!
+
+## Potential Projects
+
+We are currently collecting project ideas on the forums in the dedicated [GSoC category](https://forums.swift.org/c/development/gsoc/98).
+
+Potential mentors, please feel free to propose project ideas to this page directly, by [opening a pull request](https://github.com/swiftlang/swift-org-website/edit/main/gsoc2025/index.md) to the Swift website.
+
+You can browse previous year's project ideas here: [2024](https://www.swift.org/gsoc2024/), [2023](https://www.swift.org/gsoc2023/), [2022](https://www.swift.org/gsoc2022/), [2021](https://www.swift.org/gsoc2021/), [2020](https://www.swift.org/gsoc2020/), [2019](https://www.swift.org/gsoc2019/).
+
+
+
+### Re-implement property wrappers with macros
+
+**Project size**: 350 hours (large)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Proficiency in Swift and C++
+
+**Description**
+
+[Property wrappers](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0258-property-wrappers.md) feature is currently implemented purely within the compiler but with the addition of [Swift Macros](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0389-attached-macros.md) and [init accessors](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0400-init-accessors.md) it's now possible to remove all ad-hoc code from the compiler and implement property wrappers by using existing features.
+
+This work would remove a lot of property wrapper-specific code throughout the compiler - parsing, semantic analysis, SIL generation etc. which brings great benefits by facilitating code reuse, cleaning up the codebase and potentially fixing implementation corner cases. Macros and init accessors in their current state might not be sufficient to cover all of the property wrapper use scenarios, so the project is most likely going to require improving and expanding the aforementioned features as well.
+
+**Expected outcomes/benefits/deliverables**
+
+The outcome of this project is the complete removal of all property wrappers-specific code from the compiler. This benefits the Swift project in multiple areas - stability, testability and code health.
+
+**Potential mentors**
+
+- [Pavel Yaskevich](https://github.com/xedin)
+
+
+
+### Improve the display of documentation during code completion in SourceKit-LSP
+
+**Project size**: 175 hours (medium)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Proficiency in Swift and C++
+
+**Description**
+
+The Language Server Protocol ([LSP](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/)) offers two rich ways of displaying documentation while invoking code completion: Every code completion item can have documentation associated with it and while completing a function signature, the editor can display the available overloads, parameter names and their documentation through [signature help](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_signatureHelp). Currently, SourceKit-LSP only displays the first line of an item’s documentation in the code completion results and does not provide any signature help.
+
+This project would implement functionality to return the entire documentation for all code completion items and also implement the LSP signature help request. Both of these will require functionality to be added in [SourceKit-LSP](http://github.com/swiftlang/sourcekit-lsp) and the [compiler’s code base](https://github.com/swiftlang/swift/blob/main/lib/IDE/CodeCompletion.cpp), which determines the list of feasible code completion results.
+
+**Expected outcomes/benefits/deliverables**
+
+SourceKit-LSP will display more information and documentation about the code completion items it offers, allowing developers to pick the item that they are interested in more easily.
+
+**Potential mentors**
+
+- [Alex Hoppen](https://github.com/ahoppen)
+
+
+
+### Refactor sourcekitd to use Swift Concurrency
+
+**Project size**: 175 hours (medium)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Proficiency in Swift, including Swift 6’s concurrency model
+- Basic proficiency in C++
+
+**Description**
+
+[sourcekitd](https://github.com/apple/swift/tree/main/tools/SourceKit) is implemented in the Swift compiler’s repository to use the compiler’s understanding of Swift code to provide semantic functionality. It is currently implemented in C++. By refactoring its [request handling](https://github.com/swiftlang/swift/blob/main/tools/SourceKit/tools/sourcekitd/lib/Service/Requests.cpp) and [AST manager](https://github.com/swiftlang/swift/blob/main/tools/SourceKit/lib/SwiftLang/SwiftASTManager.cpp) to Swift, we can take advantage of Swift’s concurrency safety, improving its data race safety, making it easier to reason about and maintain.
+
+On macOS, sourcekitd is run as an XPC service, while on all other platforms, sourcekitd is run in the sourcekit-lsp process. As a stretch goal, refactoring the request handling would allow us to run sourcekitd in a separate process on Linux and Windows as well improving SourceKit-LSP's resilience as crashes inside sourcekitd would not cause a crash of the LSP process itself.
+
+**Expected outcomes/benefits/deliverables**
+
+Improved concurrency-safety of sourcekitd and better maintainability.
+
+**Potential mentors**
+
+- [Alex Hoppen](https://github.com/ahoppen)
+
+
+
+### Add more refactoring actions to SourceKit-LSP
+
+**Project size**: 90 hours (small)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Proficiency in Swift
+
+**Description**
+
+Refactoring actions assist a developer by automatically performing repetitive and mechanical tasks, such as renaming a variable. SourceKit-LSP already provides refactoring actions and this project would add new actions to SourceKit-LSP. A few new refactoring actions have already been [proposed](https://github.com/swiftlang/sourcekit-lsp/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22code%20action%22) but this project is not necessarily limited to those ideas.
+
+**Expected outcomes/benefits/deliverables**
+
+A richer set of refactorings in SourceKit-LSP that aid developers in performing mechanical tasks.
+
+**Potential mentors**
+
+- [Alex Hoppen](https://github.com/ahoppen)
+
+### Qualified name lookup for swift-syntax
+
+**Project size**: 350 hours (large)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+
+**Description**
+
+Qualified name lookup is the process by which a compiler resolves a reference `A.f` into a lookup for entities named `f` within `A`. In Swift, this can mean looking into the type `A` and all of its extensions, superclass, protocols, and so on to find visible members. The project involves building a new library to be integrated into the [swift-syntax package](https://github.com/swiftlang/swift-syntax) that implements Swift's qualified name lookup semantics, making it easy to build source tools that resolve names. The library will likely include a symbol table implementation that provides efficient lookup of a given name within a given type. It should also integrate with last year's [unqualified name lookup library project](https://forums.swift.org/t/gsoc-2024-swiftlexicallookup-a-new-lexical-name-lookup-library/75889), to provide complete support for name lookup on Swift code processed with swift-syntax.
+
+**Expected outcomes/benefits/deliverables**
+
+- Swift library providing APIs for qualified name lookup in swift-syntax
+- Documentation and tutorial for the library
+- Integration of the Swift library with the `SwiftLexicalLookup` library that implements unqualified name lookup
+
+**Potential mentors**
+
+- [Doug Gregor](https://github.com/DougGregor)
+
+### Swiftly Integration in VS Code
+
+**Project size**: 175 hours (medium)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+- Basic proficiency in TypeScript.
+- Basic proficiency in VS Code extension development.
+
+**Description**
+
+[Swiftly](https://github.com/swiftlang/swiftly) is a toolchain manager written in and built for Swift. In order to aid adoption in the Swift community, it would be beneficial to provide a rich editor integration with the existing [Swift extension for VS Code](https://github.com/swiftlang/vscode-swift). This editor integration should aid the user in installing Swiftly itself as well as with installing and selecting Swift toolchains. This will require some effort in Swiftly itself to provide a machine readable interface that any editor could use to manage Swift toolchain installations.
+
+**Expected outcomes/benefits/deliverables**
+
+- Editor integration API in Swiftly for querying available toolchains
+- VS Code should be able to install Swiftly for the user
+- VS Code should be able to install Swift toolchains via Swiftly
+- VS Code should be able to select the active Swift toolchain via Swiftly
+- VS Code should show the version of the Swift toolchain in use
+
+**Potential mentors**
+
+- [Chris McGee](https://github.com/cmcgee1024)
+- [Matthew Bastien](https://github.com/matthewbastien)
+
+### DocC Language Features in SourceKit-LSP
+
+**Project size**: 90 hours (medium)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+
+**Description**
+
+SourceKit-LSP has recently added a feature to support DocC Live Preview for editors such as VS Code. This feature could be further improved by providing language features such as go to definition as well as diagnostics for invalid/missing symbol names.
+
+**Expected outcomes/benefits/deliverables**
+
+- Syntax highlighting for DocC markdown and tutorial files
+- Go to definition for symbols that appear in DocC documentation
+- Diagnostics that report missing/invalid symbol names in DocC documentation
+
+**Potential mentors**
+
+- [Matthew Bastien](https://github.com/matthewbastien)
+- [Alex Hoppen](https://github.com/ahoppen)
+
+### Tutorial mode for the VS Code Swift extension
+
+**Project size**: 90 hours (small)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift
+- Basic proficiency in TypeScript
+- Basic proficiency in VS Code extension development
+
+**Description**
+
+_This project can possibly be combined with the Swiftly Integration in VS Code project and the Tutorial mode for Swift project. When submitting project application for both together, please then mark it as a medium (175 hours) project._
+
+Right now there isn't a whole lot of guidance on how to use the [Swift extension for VS Code](https://github.com/swiftlang/vscode-swift) once it is installed. Apart from reading [an article about it](https://www.swift.org/documentation/articles/getting-started-with-vscode-swift.html) and the "Details" tab of the Swift extension in VS Code it's up to the user to realize that a Swift toolchain will have to be installed and figure out the workflow to Build, Run, Test and Debug code. As well, people who are installing the extension could be new to programming and Swift in general. A tutorial mode that will show the features of the extension will be greatly beneficial for first time users.
+
+The feature can possibly be implemented with [VS Code Walkthrough](https://code.visualstudio.com/api/ux-guidelines/walkthroughs) mode or something similar to the [CodeTour](https://github.com/microsoft/codetour) extension.
+
+**Expected outcomes/benefits/deliverables**
+
+- A better onboarding experience for first time users of the VS Code Swift extension
+- Users learn about the features of the extension
+
+**Potential mentors**
+
+- Either [Adam Ward](https://github.com/award999) or [Paul Lemarquand](https://github.com/plemarquand) or [Matthew Bastien](https://github.com/matthewbastien)
+- [Rishi Benegal](https://github.com/rbenegal)
+
+### Tutorial mode for Swift in the VS Code Extension
+
+**Project size**: 90 hours (small)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift
+- Basic proficiency in TypeScript
+- Basic proficiency in VS Code extension development
+
+**Description**
+
+_This project can possibly be combined with the Swiftly Integration in VS Code project and the Tutorial mode for VS Code Swift project._
+
+Many users who install the VS Code swift extension could be new to Swift and programming in general. A tutorial mode that will show features of the programming language could allow users to experiment with their programs interactively and greatly enhance their learning experience. This tutorial mode can include examples from the [Swift Book](https://docs.swift.org/swift-book), a VS Code version of the [DocC tutorials](https://developer.apple.com/documentation/xcode/slothcreator_building_docc_documentation_in_xcode), [swift-testing](https://developer.apple.com/documentation/testing/) tutorials and code formatting tutorials using [swift-format](https://github.com/swiftlang/swift-format).
+
+The feature can possibly be implemented with [VS Code Walkthrough](https://code.visualstudio.com/api/ux-guidelines/walkthroughs) mode or something similar to the [CodeTour](https://github.com/microsoft/codetour) extension.
+
+**Expected outcomes/benefits/deliverables**
+
+- A better onboarding experience for users who want to learn more about Swift
+- Users learn about the features of the Swift programming language
+
+**Potential mentors**
+
+- Either [Adam Ward](https://github.com/award999) or [Paul Lemarquand](https://github.com/plemarquand) or [Matthew Bastien](https://github.com/matthewbastien)
+- [Rishi Benegal](https://github.com/rbenegal)
+
+### Improved console output for Swift Testing
+
+**Project size**: 175 hours (medium)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+
+**Description**
+
+Enhance Swift Testing's reporting of test results to the console/terminal. Consider adding features like live progress reporting, nested output reflecting suite hierarchy, test metadata (display names, tags), parameterized test arguments, and more terminal colors. Perhaps include user-configurable options. If time allows, implement several alternatives and present them to the community (and the Testing Workgroup) for consideration. Factor code as portably as possible to support many platforms, and so it could be incorporated into a supervisory “harness” process in the future.
+
+**Expected outcomes/benefits/deliverables**
+
+- Add a new component in the [swift-testing](https://github.com/swiftlang/swift-testing) repository which receives events from the testing library and decides how to reflect them in console output.
+- Modify supporting tools such as Swift Package Manager to allow enabling or configuring this functionality.
+- Land the changes behind an experimental feature flag initially.
+- Submit a proposal to the community and the Testing Workgroup to formally enable the feature.
+- Summarize your effort with a demo of the new functionality including screenshots or recordings.
+
+**Potential mentors**
+
+- [Stuart Montgomery](https://github.com/stmontgomery)
+
+### Improved command line tool documentation
+
+**Project size**: 175 hours (medium)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+
+**Description**
+
+Swift Argument Parser recently added a [command plugin](https://github.com/apple/swift-argument-parser/pull/694) to generate documentation markup for a command line tool.
+This plugin could be improved by providing support for generating separate pages for each command and by leveraging additional markdown syntax to organize command line flags into sections and display possible values and default values.
+
+Beyond the markdown output, this plugin could be further improved by generating a ["symbol graph"](https://github.com/swiftlang/swift-docc-symbolkit/tree/main) that describe each command and its flags, options, and subcommands. By describing the commands' structure, tools like [Swift DocC](https://github.com/swiftlang/swift-docc/tree/main) can further customize the display of command line tool documentation, support links to individual flags, and allow developers to extend or override the documentation for individual flags in ways that isn't overwritten when regenerating the documentation markup from the plugin. If time allows, prototype some enhancement to command line documentation in Swift DocC that leverage the information from the command symbol graph file.
+
+**Expected outcomes/benefits/deliverables**
+
+- A richer markdown output from the plugin.
+- Support for generating separate pages for each command.
+- Output a supplementary symbol graph file that describe the commands' structure.
+
+**Potential mentors**
+
+- [David Rönnqvist](https://github.com/d-ronnqvist)
+
+### Documentation coverage
+
+ **Project size**: 90 hours (small)
+
+ **Estimated difficulty**: Intermediate
+
+ **Recommended skills**
+
+ - Basic proficiency in Swift.
+
+ **Description**
+
+ Enhance Swift DocC's experimental documentation coverage feature to write coverage metrics in a new extensible format that other tools can read and display.
+ Define a few types of metrics—for example Boolean (has documentation: true/false), Fraction (2/3 parameters are documented), Percentage, etc.—for this format.
+ Explore ideas for what documentation coverage information would be useful to emit. Explore ideas for how another tool could display that coverage information.
+
+ **Expected outcomes/benefits/deliverables**
+
+ - Land the documentation coverage output format changes for the experimental feature in DocC.
+ - Submit a pitch to the community and the Documentation Workgroup to formally enable the documentation coverage feature in DocC.
+ - Summarize your effort with a demo of the new metrics and examples of how another tool could display that information.
+
+ **Potential mentors**
+
+ - [David Rönnqvist](https://github.com/d-ronnqvist)
+
+### OpenAPI integration with DocC
+
+**Project size**: 350 hours (large)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+- Basic knowledge in HTTP APIs.
+
+**Description**
+
+[OpenAPI](https://www.openapis.org/) is a standard for documenting HTTP services. It allows creating documents in YAML or JSON format that can be utilized by various tools to automate workflows, such as generating the required code for sending and receiving HTTP requests.
+
+OpenAPI is known for its tooling to generate documentation, but in the Swift ecosystem, developers are already familiar with how [DocC](https://github.com/swiftlang/swift-docc) renders documentation for Swift and Objective-C APIs. To enhance consistency and improve the developer experience, we aim to extend DocC’s support to OpenAPI documents.
+
+**Expected outcomes/benefits/deliverables**
+
+As part of the Google Summer of Code project, the student will develop a library/tool that can generate DocC documentation from an OpenAPI document.
+
+Strech goals:
+
+* Integrate the tool into the [Swift OpenAPI Generator](https://github.com/apple/swift-openapi-generator).
+* Create OpenAPI Doc to DocC Live Preview plugin for VS Code.
+
+**Potential mentors**
+
+- [Sofía Rodríguez](https://github.com/sofiaromorales)
+- [Si Beaumont](https://github.com/simonjbeaumont)
+- [Honza Dvorsky](https://github.com/czechboy0)
+
+### JNI mode for swift-java's source jextract tool
+
+**Project size**: 350 hours (large)
+
+**Estimated difficulty**: Intermediate
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+- Basic proficiency in Java, since the source generator will be emitting both Java and Swift code.
+
+**Description**
+
+The existing [swift-java](https://github.com/swiftlang/swift-java) Java interoperability project currently supports both JNI and Java's new Foreign Function & Memory API's,
+however the latter source generator which works by analysis of existing Swift code, and emitting Java "accessors" to these
+currently only works with JDK 22+ because it uses FFM for its implementation. It would be possible–and beneficial for platforms
+where JDK 22+ is not available–to allow the `jextract` tool also operate in a limited functionality JNI mode.
+
+This project would kickstart the work on a JNI mode for the `jextract` tool, allowing for calling for any Swift APIs
+from Java, using these generated Java accessor classes.
+
+**Expected outcomes/benefits/deliverables**
+
+- Provide a new JNI mode for the `jextract`
+- Achieve feature parity with the current day FFM mode of jextract
+- The project can be stretched to provide more features and continue work on jextract, providing more flexibility in the tool
+
+**Potential mentors**
+
+- [Konrad 'ktoso' Malawski](https://github.com/ktoso)
+
+
+
+### Example project name
+
+**Project size**: N hours
+
+**Estimated difficulty**: ???
+
+**Recommended skills**
+
+- Basic proficiency in Swift.
+- ...
+
+**Description**
+
+Description of the project goes here.
+
+**Expected outcomes/benefits/deliverables**
+
+- Expected deliverables of the project go here
+
+**Potential mentors**
+
+- Mentor name and link to their github
+
diff --git a/index.md b/index.md
index 8c60b85ee..0fc00e500 100644
--- a/index.md
+++ b/index.md
@@ -17,7 +17,7 @@ atom: true
+
+[Things Cloud](https://culturedcode.com/things/cloud/) serves as the backbone of the app’s experience, silently synchronizing to-dos across devices. The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind.
+
+
+ 
+
+
+## Switching to Swift
+
+Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.
+
+A full rewrite is usually a last resort, but in our case, it was the only viable path for Things Cloud. We explored various programming languages including Java, Python 3, Go, and even C++. However, Swift – which was already a core part of our client apps – stood out for its potential and unique benefits. Swift promised excellent performance, predictable memory management through [ARC](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/), an expressive type system for reliability and maintainability, and seamless interoperability with C and C++.
+
+While we initially had concerns that Swift's server support wasn’t as mature as that found in other ecosystems, both Apple and the open-source community had shown strong commitment to its evolution. Swift had reliably compiled on Linux for a long time; the Swift Server workgroup had coordinated server efforts since 2016; the [SwiftNIO library](https://github.com/apple/swift-nio) gave us confidence in the foundational capabilities, and [Vapor](https://vapor.codes) provided all the tools to get us up and running quickly.
+
+Convinced by these benefits and the opportunity to use the same language for client and server development, we embarked on a three-year journey to rewrite Things Cloud. We’ve been using it internally for the past two years, and it has now been live in production for over a year.
+
+## The new Swift-based service architecture
+
+We’ll outline the core components of our new service architecture, highlighting the Swift packages we use. We’ve found that these components work well together to provide reliability and stability, and we believe this serves as a valuable reference point for others considering a similar transition to Swift.
+
+
+ Things Cloud synchronizes to-dos across different devices.
+
+ 
+
+
+### Code
+
+- Our **Swift** server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes.
+- It uses **Vapor** as an HTTP web framework, which uses **SwiftNIO** as its underlying network application framework.
+- We compile a single “monolith” binary from our Swift source code, but use it to run multiple services, each configured by passing different parameters at runtime.
+- We use **Xcode** for its robust suite of tools for development, debugging, and testing. It provides us with a familiar and consistent experience across both server and client environments.
+
+### Deployment
+
+- **AWS** hosts our entire platform, and is entirely managed by **Terraform**, an infrastructure as code tool.
+- We use a continuous integration pipeline to automate tests and build our Swift code into a **Docker** image. This is then deployed in a **Kubernetes** cluster alongside other components.
+- The **HAProxy** load balancer is used to route client traffic to the appropriate Swift service in the cluster.
+
+### Storage
+
+- Persistent data is stored in **Amazon Aurora MySQL**, a relational database, which we connect to with **MySQLKit**.
+- To keep the database small, we’re offloading less-used data to **S3**, which we access via the **Soto** package.
+- More ephemeral data, such as push notifications and caches, is stored in **Redis**, an in-memory key-value database, which we access via **RediStack**.
+
+### Other Services
+
+- The **APNSwift** package is used to communicate with the Apple Push Notification service.
+- **AWS Lambda**, a serverless compute service, powers our **Mail to Things** feature. This process is written in Python 3 due to its mature libraries for the processing of incoming emails. The results are passed to Swift using **Amazon Simple Queue Service**.
+
+### Monitoring
+
+- We take the resilience of Things Cloud seriously and go to great lengths to ensure it.
+- In Swift, we generate JSON logs using our own logger. To produce metrics, we’re using the **Swift Prometheus**.
+- We use **Amazon CloudWatch** to store and analyze logs and metrics. It triggers Incidents, which reach the responsible engineer via **PagerDuty**.
+- To test how well our service can recover from transient errors, we employ **chaos testing**. Each day, our self-written chaos agent performs random disruptive actions such as terminating a Swift service or restarting the database. We then verify that the system recovers as expected.
+
+## Results
+
+We wanted to thoroughly test the performance and stability of the new Swift service architecture before it was deployed in production. So during the development phase, we deployed the new system alongside the existing legacy system. While the legacy system continued to be the operational service for all requests, the new system also processed them independently using its own logic and database.
+
+This approach enabled us to develop and test the new system under real-world conditions without any risk to the user experience. Thanks to the confidence we built in the new system's robustness and reliability through evaluating it with production workloads, we were able to deploy a hardened system from the very beginning.
+
+Now, with over a full year in production, we're pleased to report that Swift has fulfilled its promise for server-side development. It’s fast and memory-efficient. Our Kubernetes cluster comprises four instances, each with two virtual CPUs and 8 GB of memory, and has handled traffic peaks of up to 500 requests per second. Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically.
+
+
+ Overview of our new Swift-based service architecture.
+
+ 
+
+
+And one extra win: Swift’s outstanding performance allowed us to replace our custom C-based push notification service with a Swift-based one; this significantly simplified our codebase and operations.
+
+## Conclusions
+
+Swift turned out to be a great choice for server usage. It delivered on everything we had hoped for: We’re now using a modern and expressive programming language, the code runs and performs well, and the Swift ecosystem provides all the integrations we need. With a year of production use, we haven’t encountered a single operational issue.
+
+For more information on our journey and experiences, you might enjoy [our recent talk](https://youtu.be/oJArLZIQF8w?si=hLr6g5MmYH3-5K1c) at the [ServerSide.Swift](https://www.serversideswift.info) conference.
+
+We encourage other teams to consider using Swift for server-oriented projects. While we chose to undergo a complete rewrite, the gradual adoption of Swift is also an intriguing option, especially considering the recently announced initiative aimed at [enhancing Java interoperability](https://github.com/swiftlang/swift-java).
+
+As for us, we believe our server architecture is in its best shape ever, and we’re thrilled about the new features we can build upon this solid foundation.
diff --git a/_posts/2025-03-28-introducing-swiftly_10.md b/_posts/2025-03-28-introducing-swiftly_10.md
new file mode 100644
index 000000000..7d1bf5a30
--- /dev/null
+++ b/_posts/2025-03-28-introducing-swiftly_10.md
@@ -0,0 +1,97 @@
+---
+layout: post
+published: true
+date: 2025-03-28 6:00:00
+title: Introducing swiftly 1.0
+author: [chris-mcgee]
+---
+
+Today we’re delighted to introduce the first stable release of swiftly, a Swift version manager that takes the pain out of installing, managing and updating your Swift toolchain.
+
+The latest version of Swift is bundled with Xcode for writing apps for Apple platforms. But perhaps you want to install Swift on a different platform like Linux, or use a different version of the toolchain for building services or command line tools. Downloading, extracting and installing a trusted build of Swift along with the relevant dependencies for your operating system can require quite a few manual and error-prone steps.
+
+swiftly has been around for some years as a community-supported tool for Swift developers using Linux. With this release, we’re officially supporting it as part of the core Swift toolchain, including hosting it as part of the [Swift GitHub organization](https://github.com/swiftlang). We’ve also added macOS support to make it easier to install Swift separately from Xcode.
+
+## Introducing swiftly
+
+swiftly is the best tool to install the standalone toolchain, providing commands to install Swift on a new system, update to the latest stable version, and experiment or test with nightly snapshots or older versions. It also makes it easy to switch effortlessly between multiple installed toolchains. You can even add a file to your project repository so swiftly will use the same toolchain version for all members of your development team.
+
+Naturally, swiftly itself is written in Swift, and is able to update itself to the latest version.
+
+## Quick tour
+
+Let's take a look at some of the features of swiftly!
+
+To get started, visit [swift.org/install](/install) and install it.
+
+swiftly will provide directions after installation if there are any system packages, or shell commands needed for smooth operation of the new toolchain.
+
+The latest Swift toolchain is installed as the default, so you can immediately use it to start a new project. For example:
+
+```
+$ swift package init
+```
+
+The `swiftly use` command selects the default toolchain for Swift commands (e.g. `swift test`, `swift build`):
+
+```
+$ swiftly use 6.0.3
+$ swift --version
+--
+Apple Swift version 6.0.3 (swiftlang-6.0.3.1.2 clang-1600.0.28.6)
+Target: arm64-apple-macosx15.0
+```
+
+At a later point, if there’s a new release of Swift you can install it alongside the existing toolchain with the `latest` command:
+
+```
+$ swiftly install latest
+```
+
+Pre-release of versions of Swift are available, including nightly "snapshot" toolchains. They can be easily listed using swiftly:
+
+```
+$ swiftly list-available main-snapshot
+--
+Available main development snapshot toolchains
+----------------------------------------------
+main-snapshot-2025-03-25
+...
+```
+
+Once you’ve identified a snapshot toolchain, it can be installed using its name:
+
+```
+$ swiftly install main-snapshot-2025-03-25
+--
+Installing main-snapshot-2025-03-25
+```
+
+Another way to temporarily use a specific version of Swift is to use the special '+' selector. With this syntax, you don't need to first switch to a different toolchain:
+
+```
+$ swiftly run lldb +main-snapshot-2025-03-25
+--
+(lldb) _
+```
+
+If you’re building a SwiftPM project in a team setting and want to enforce a common version of the Swift toolchain on all contributors, simply create a `.swift-version` file in the root of your project folder with the desired version (e.g. “6.0.3”).
+
+As swiftly is updated with new features and bug fixes, you can run `swiftly self-update` to check and install new releases.
+
+## How swiftly works
+
+By writing swiftly in Swift, we’re able to take advantage of the language’s features, support, and ecosystem of related projects. Swift comes with standard library features for working with the filesystem in its [Foundation](https://developer.apple.com/documentation/foundation/) module. For network operations [Async HTTP Client](https://github.com/swift-server/async-http-client) is there to work the HTTP requests. And to retrieve the latest Swift release, swiftly uses the [Swift OpenAPI](https://github.com/apple/swift-openapi-generator) plugin to generate the code to interact with the [swift.org](http://swift.org/) website. Lastly, it takes advantage of Swift’s interoperability with C to use the existing libarchive library to work with archives. swiftly uses libarchive to extract the toolchains downloaded from the Swift website and the integration is simple.
+
+It can be challenging to build shell programs that work well across multiple platforms with minimal system dependencies; this motivated us to switch swiftly away from using a shell program to install it and become a self-installing binary application. swiftly has access to excellent argument parsing capabilities, beautiful `--help` screens, and the full standard library.
+
+The only remaining problem was being able to deliver the operating system and processor architecture specific binary to the users system with simplicity. The [swift.org](http://swift.org/) website helps with operating system detection, but it cannot reliably detect the Linux distribution. Luckily, there is the [Swift Static Linux SDK](https://www.swift.org/documentation/articles/static-linux-getting-started.html) that makes binaries that work with a wide range of distributions. The processor architecture can be determined on most unixes using `uname -m` . The result of all of this is the simplicity of a copy and paste from the website to your terminal and get started with Swift.
+
+## Installing Swift, swiftly
+
+Moving forward, swiftly will become the default way to install Swift outside of Xcode. The initial version supports macOS and a variety of Linux distributions, including Ubuntu, Debian, Fedora, Red Hat Enterprise Linux and Amazon Linux.
+
+The [swiftly documentation](/swiftly/documentation/swiftlydocs/) provides further information about [using swiftly in a CI/CD environment](/swiftly/documentation/swiftly/automated-install), as well as setting proxy servers and custom install locations for enterprise environments. swiftly is an open source project, and so you can raise new issues or contribute pull requests at its [GitHub repository](https://github.com/swiftlang/swiftly). You can also [ask questions or discuss swiftly on the Swift Forums](https://forums.swift.org/tag/swiftly).
+
+Special thanks to Patrick Freed for creating swiftly, contributing it to the Swift organization, and his continued contributions to this valuable tool. The community is what makes Swift amazing!
+
diff --git a/_posts/2025-03-31-swift-6.1-released.md b/_posts/2025-03-31-swift-6.1-released.md
new file mode 100644
index 000000000..55e68247e
--- /dev/null
+++ b/_posts/2025-03-31-swift-6.1-released.md
@@ -0,0 +1,172 @@
+---
+layout: post
+published: true
+date: 2025-03-31 10:00:00
+title: Swift 6.1 Released
+author: [hborla]
+---
+
+Swift 6.1 is now available!
+
+This release includes new language enhancements to improve productivity, diagnostics improvements, package traits, and ongoing work to improve data-race safety usability and compile times.
+
+Read on for an overview of the changes to the language, package manager, and next steps for getting started with Swift 6.1.
+
+## Language and Standard Library
+
+### Concurrency
+
+Swift’s concurrency model allows writing `nonisolated` on properties and functions to indicate that an API is safe to call from any concurrent context. Swift 6.1 extends `nonisolated` to types and extensions. This allows you to write `nonisolated` to prevent `@MainActor` inference on a type, or to apply `nonisolated` to all methods in an extension without having to annotate every method:
+
+```swift
+@MainActor
+struct S {
+ let id: Int
+ let name: String
+
+ // mutable state and MainActor methods
+}
+
+nonisolated extension S: CustomStringConvertible, Equatable {
+ var description: String {
+ "id: \(id), name: \(name)"
+ }
+
+ static func ==(lhs: S, rhs: S) -> Bool {
+ lhs.id == rhs.id
+ }
+}
+```
+
+Swift 6.1 also improves type inference for task groups by inferring the child task result type of `withTaskGroup` and `withThrowingTaskGroup`. Previously, you always had to write the child task result type as an argument when creating the task group:
+
+```swift
+let messages = await withTaskGroup(of: Message.self) { group in
+ for id in ids {
+ group.addTask { await downloadMessage(for: id) }
+ }
+
+ var messages: [Message] = []
+ for await message in group {
+ messages.append(message)
+ }
+ return messages
+}
+```
+
+In Swift 6.1, the child task result type can be inferred from the task group closure:
+
+```swift
+// No need for `(of: Message.self)` like before.
+let messages = await withTaskGroup { group in
+ for id in ids {
+ group.addTask { await downloadMessage(for: id) }
+ }
+
+ var messages: [Message] = []
+ for await message in group {
+ messages.append(message)
+ }
+ return messages
+}
+```
+
+The approachability of data-race safety remains an area of active development; you can find an overview of the approach in the [vision document for improving the approachability of data-race safety](https://github.com/swiftlang/swift-evolution/blob/main/visions/approachable-concurrency.md). Many Swift Evolution proposals implementing the features described in the vision document are under active review, and your feedback will help shape these improvements.
+
+### Implementing Objective-C types in Swift
+
+Swift 6.1 includes a new attribute, `@implementation`, which can be used together with `@objc` to provide an implementation for a declaration that has been imported from Objective-C. You can write `@objc @implementation` on a Swift `extension` to replace an Objective-C `@implementation` block.
+
+You write headers as normal for an Objective-C class, but instead of writing an `@implementation` in an Objective-C file, you write an `@objc @implementation extension` in a Swift file. You can even port an existing class’s implementation to Swift one category at a time without breaking backwards compatibility.
+
+### Productivity enhancements
+
+Swift allows including trailing commas in collection literals to make it easy to append, remove, reorder, or comment out the last element as any other element:
+
+```swift
+let rank = [
+ "Player 1",
+ "Player 3",
+ "Player 2",
+]
+```
+
+Swift 6.1 extends trailing comma support to tuples, parameter and argument lists, generic parameter lists, closure capture lists, and string interpolations:
+
+```swift
+let numbers = [1, 2, 0, 3, 4, 0, 0, 5]
+
+let subsequences = numbers.split(
+ separator: 0,
+ maxSplits: 1,
+)
+```
+
+In addition to improved development ergonomics, code generation tools like plugins and macros can be simplified, because generating a comma-separated list no longer needs a special condition for the last element.
+
+You can find a complete list of language proposals that were accepted through the [Swift Evolution](https://github.com/swiftlang/swift-evolution) process and implemented in Swift 6 on the [Swift Evolution dashboard](/swift-evolution/#?version=6.1).
+
+## Package and build improvements
+
+Swift 6.1 introduces *package traits*, a new configuration for packages that allows them to offer different APIs and features when used in specific environments, such as Embedded Swift and WebAssembly. Package authors can define a set of traits in their `Package.swift` that their package offers, which provide a way to express conditional compilation and optional dependencies. The package can specify a set of default traits that are enabled in clients, and clients can customize the traits they use when they declare the dependency:
+
+```swift
+dependencies: [
+ .package(
+ url: "https://github.com/Org/SomePackage.git",
+ from: "1.0.0",
+ traits: [
+ .default, // enable all of the package's default traits
+ "Embedded"
+ ]
+ ),
+]
+```
+
+Many editing features, such as jump to definition for APIs in libraries you’re using, are powered by indexing. Before Swift 6.1, indexing occurred when you built your project, which meant that any additions or changes to the library were only surfaced by those editing features after you perform a build. Swift 6.1 enables [background indexing](https://github.com/swiftlang/sourcekit-lsp/blob/main/Documentation/Enable%20Experimental%20Background%20Indexing.md) by default for SwiftPM projects in SourceKit-LSP. Cross-module and global functionality stays updated as you make changes to your project.
+
+## Swift Testing
+
+Swift 6.1 enables custom Swift Testing traits to perform logic before or after tests run in order to share set-up or tear-down logic. If you write a custom trait type which conforms to the new `TestScoping` protocol, you can implement a method to customize the scope in which each test or suite the trait is applied to will execute. For example, you could implement a trait which binds a task local value to a mocked resource:
+
+```swift
+struct MockAPICredentialsTrait: TestTrait, TestScoping {
+ func provideScope(for test: Test, testCase: Test.Case?, performing function: @Sendable () async throws -> Void) async throws {
+ let mockCredentials = APICredentials(apiKey: "fake")
+ try await APICredentials.$current.withValue(mockCredentials) {
+ try await function()
+ }
+ }
+}
+
+extension Trait where Self == MockAPICredentialsTrait {
+ static var mockAPICredentials: Self { Self() }
+}
+
+@Test(.mockAPICredentials)
+func example() {
+ // Validate API usage, referencing `APICredentials.current`...
+}
+```
+
+For more details, see [ST-0007: Test Scoping Traits](https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0007-test-scoping-traits.md). Swift Testing in Swift 6.1 also includes refined versions of the `#expect(throws:)` and `#require(throws:)` macros which return their caught errors, making inspecting them in test functions more ergonomic ([ST-0006](https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0006-return-errors-from-expect-throws.md)).
+
+## Swift-DocC
+
+Swift-DocC introduces a more human readable and human writable alternative for symbol link disambiguation based on parameter type and return type information. For example, consider these three function overloads with different parameter types and return types:
+
+```swift
+func doSomething(first: String, second: Int) -> Double
+func doSomething(first: String?, second: Int) -> Float
+func doSomething(first: String?, second: Int) -> Double
+```
+
+Previously, if you wrote a link to one of these overloads you needed to include a short hash of that symbol’s unique identifier to disambiguate the link and uniquely reference the specific overload. Swift-DocC's warnings aided in writing these hashes but a person can't decode the resulting hash suffix (`-3c5j`) to determine which overload the link is referring to. Now, you can use a combination of parameter types and return types—like `-(String,_)`, `->Float,` or `-(String?,_)->Double`—to disambiguate the link and uniquely reference a specific overload.
+
+You can discover the minimal combination of parameter types and return types for each overload from Swift-DocC’s warnings about ambiguous symbol links. For more details, see [the Ambiguous Symbol Links section of Linking to Symbols and Other Content](/documentation/docc/linking-to-symbols-and-other-content#Ambiguous-Symbol-Links).
+
+## Install Swift 6.1
+
+You can try out these exciting new developments in Swift 6.1 today!
+
+If you're building apps for Apple platforms, Swift 6.1 is included in Xcode 16.3, now available from the App Store. And the easiest way to install the standalone Swift 6.1 toolchain is using [swiftly](/blog/introducing-swiftly_10/), the new Swift version manager that runs on macOS and Linux. Additional installation methods, including for Windows, are included on the [Install Swift](/install/) page.
diff --git a/api/v1/install/dev/6.1/amazonlinux2.json b/api/v1/install/dev/6.1/amazonlinux2.json
new file mode 100644
index 000000000..bfedbaf0c
--- /dev/null
+++ b/api/v1/install/dev/6.1/amazonlinux2.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.amazonlinux2 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.amazonlinux2-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/6.1/centos7.json b/api/v1/install/dev/6.1/centos7.json
new file mode 100644
index 000000000..57acbb9b4
--- /dev/null
+++ b/api/v1/install/dev/6.1/centos7.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.centos7 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.centos7-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/6.1/debian12.json b/api/v1/install/dev/6.1/debian12.json
new file mode 100644
index 000000000..7b073a90a
--- /dev/null
+++ b/api/v1/install/dev/6.1/debian12.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.debian12 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.debian12-aarch64 | jsonify }}
+}
diff --git a/api/v1/install/dev/6.1/fedora39.json b/api/v1/install/dev/6.1/fedora39.json
new file mode 100644
index 000000000..7e73557af
--- /dev/null
+++ b/api/v1/install/dev/6.1/fedora39.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.fedora39 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.fedora39-aarch64 | jsonify }}
+}
diff --git a/api/v1/install/dev/6.1/macos.json b/api/v1/install/dev/6.1/macos.json
new file mode 100644
index 000000000..66d4c4671
--- /dev/null
+++ b/api/v1/install/dev/6.1/macos.json
@@ -0,0 +1,4 @@
+---
+layout: none
+---
+{ "universal": {{ site.data.builds.swift-6_1-branch.xcode | jsonify }}}
diff --git a/api/v1/install/dev/6.1/static-sdk.json b/api/v1/install/dev/6.1/static-sdk.json
new file mode 100644
index 000000000..eb27f599e
--- /dev/null
+++ b/api/v1/install/dev/6.1/static-sdk.json
@@ -0,0 +1,4 @@
+---
+layout: none
+---
+{{ site.data.builds.swift-6_1-branch.static_sdk | jsonify }}
\ No newline at end of file
diff --git a/api/v1/install/dev/6.1/ubi9.json b/api/v1/install/dev/6.1/ubi9.json
new file mode 100644
index 000000000..53e3e0961
--- /dev/null
+++ b/api/v1/install/dev/6.1/ubi9.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.ubi9 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.ubi9-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/6.1/ubuntu2004.json b/api/v1/install/dev/6.1/ubuntu2004.json
new file mode 100644
index 000000000..08801771c
--- /dev/null
+++ b/api/v1/install/dev/6.1/ubuntu2004.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.ubuntu2004 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.ubuntu2004-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/6.1/ubuntu2204.json b/api/v1/install/dev/6.1/ubuntu2204.json
new file mode 100644
index 000000000..7f0e7a623
--- /dev/null
+++ b/api/v1/install/dev/6.1/ubuntu2204.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.ubuntu2204 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.ubuntu2204-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/6.1/ubuntu2404.json b/api/v1/install/dev/6.1/ubuntu2404.json
new file mode 100644
index 000000000..69cf7004e
--- /dev/null
+++ b/api/v1/install/dev/6.1/ubuntu2404.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.ubuntu2404 | jsonify }},
+ "aarch64": {{ site.data.builds.swift-6_1-branch.ubuntu2404-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/6.1/windows10.json b/api/v1/install/dev/6.1/windows10.json
new file mode 100644
index 000000000..27248dddb
--- /dev/null
+++ b/api/v1/install/dev/6.1/windows10.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.swift-6_1-branch.windows10 | jsonify }},
+ "arm64": {{ site.data.builds.swift-6_1-branch.windows10-arm64 | jsonify }}
+}
diff --git a/api/v1/install/dev/main/debian12.json b/api/v1/install/dev/main/debian12.json
new file mode 100644
index 000000000..06e82c1fb
--- /dev/null
+++ b/api/v1/install/dev/main/debian12.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.development.debian12 | jsonify }},
+ "aarch64": {{ site.data.builds.development.debian12-aarch64 | jsonify }}
+}
diff --git a/api/v1/install/dev/main/fedora39.json b/api/v1/install/dev/main/fedora39.json
new file mode 100644
index 000000000..d40ebaf1c
--- /dev/null
+++ b/api/v1/install/dev/main/fedora39.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.development.fedora39 | jsonify }},
+ "aarch64": {{ site.data.builds.development.fedora39-aarch64 | jsonify }}
+}
diff --git a/api/v1/install/dev/main/ubuntu2404.json b/api/v1/install/dev/main/ubuntu2404.json
new file mode 100644
index 000000000..ea7ca3316
--- /dev/null
+++ b/api/v1/install/dev/main/ubuntu2404.json
@@ -0,0 +1,6 @@
+---
+layout: none
+---
+{ "x86_64": {{ site.data.builds.development.ubuntu2404 | jsonify }},
+ "aarch64": {{ site.data.builds.development.ubuntu2404-aarch64 | jsonify}}
+}
diff --git a/api/v1/install/dev/main/windows10.json b/api/v1/install/dev/main/windows10.json
index c667acd45..b6f022a78 100644
--- a/api/v1/install/dev/main/windows10.json
+++ b/api/v1/install/dev/main/windows10.json
@@ -1,4 +1,6 @@
---
layout: none
---
-{ "x86_64": {{ site.data.builds.development.windows10 | jsonify }}}
+{ "x86_64": {{ site.data.builds.development.windows10 | jsonify }},
+ "arm64": {{ site.data.builds.development.windows10-arm64 | jsonify }}
+}
diff --git a/api/v1/swiftly.json b/api/v1/swiftly.json
new file mode 100644
index 000000000..f9c768f9b
--- /dev/null
+++ b/api/v1/swiftly.json
@@ -0,0 +1,4 @@
+---
+layout: none
+---
+{{ site.data.builds.swiftly_release | jsonify }}
diff --git a/assets/images/getting-started-with-vscode-swift/installation.png b/assets/images/getting-started-with-vscode-swift/installation.png
index df445844b..d11d85a99 100644
Binary files a/assets/images/getting-started-with-vscode-swift/installation.png and b/assets/images/getting-started-with-vscode-swift/installation.png differ
diff --git a/assets/images/how-swifts-server-support-powers-things-cloud/new-backend-overview.png b/assets/images/how-swifts-server-support-powers-things-cloud/new-backend-overview.png
new file mode 100644
index 000000000..a741f0f1c
Binary files /dev/null and b/assets/images/how-swifts-server-support-powers-things-cloud/new-backend-overview.png differ
diff --git a/assets/images/how-swifts-server-support-powers-things-cloud/performance-comparison.png b/assets/images/how-swifts-server-support-powers-things-cloud/performance-comparison.png
new file mode 100644
index 000000000..17f815c9c
Binary files /dev/null and b/assets/images/how-swifts-server-support-powers-things-cloud/performance-comparison.png differ
diff --git a/assets/images/how-swifts-server-support-powers-things-cloud/things-cloud-with-devices.png b/assets/images/how-swifts-server-support-powers-things-cloud/things-cloud-with-devices.png
new file mode 100644
index 000000000..15403a272
Binary files /dev/null and b/assets/images/how-swifts-server-support-powers-things-cloud/things-cloud-with-devices.png differ
diff --git a/assets/images/how-swifts-server-support-powers-things-cloud/things-logo.png b/assets/images/how-swifts-server-support-powers-things-cloud/things-logo.png
new file mode 100644
index 000000000..0b98a107e
Binary files /dev/null and b/assets/images/how-swifts-server-support-powers-things-cloud/things-logo.png differ
diff --git a/assets/images/icon-bluesky.svg b/assets/images/icon-bluesky.svg
new file mode 100644
index 000000000..b46f53321
--- /dev/null
+++ b/assets/images/icon-bluesky.svg
@@ -0,0 +1,3 @@
+
diff --git a/assets/images/icon-mastodon.svg b/assets/images/icon-mastodon.svg
new file mode 100644
index 000000000..70b504eb3
--- /dev/null
+++ b/assets/images/icon-mastodon.svg
@@ -0,0 +1,3 @@
+
diff --git a/assets/images/icon-x.svg b/assets/images/icon-x.svg
new file mode 100644
index 000000000..908bdcee2
--- /dev/null
+++ b/assets/images/icon-x.svg
@@ -0,0 +1,3 @@
+
diff --git a/assets/images/vscode-extension-blog/vscode-swift-2.png b/assets/images/vscode-extension-blog/vscode-swift-2.png
new file mode 100644
index 000000000..644d56143
Binary files /dev/null and b/assets/images/vscode-extension-blog/vscode-swift-2.png differ
diff --git a/assets/javascripts/application.js b/assets/javascripts/application.js
index 5a3841eca..f807674bf 100644
--- a/assets/javascripts/application.js
+++ b/assets/javascripts/application.js
@@ -87,5 +87,24 @@ layout: source
}
})
}
+
+ if (navigator && navigator.clipboard) {
+ const copyCodeButtons = document.querySelectorAll('[class^="language-"] button');
+
+ copyCodeButtons.forEach(function(button) {
+ const codeElement = button.parentElement.querySelector('code');
+ const originalText = button.innerText;
+
+ button.addEventListener('mousedown', async function() {
+ await navigator.clipboard.writeText(codeElement.innerText);
+
+ button.innerText = 'Copied!';
+
+ setTimeout(() => {
+ button.innerText = originalText;
+ }, 1000);
+ });
+ });
+ }
});
})();
diff --git a/assets/stylesheets/_colors.scss b/assets/stylesheets/_colors.scss
index 9a48299d7..2e189c798 100644
--- a/assets/stylesheets/_colors.scss
+++ b/assets/stylesheets/_colors.scss
@@ -1,7 +1,11 @@
+@use './core/_vars' as mixvars;
+@use './core/colors/_light' as mixlight;
+@use './core/colors/_dark' as mixdark;
+
body {
color-scheme: light dark;
- @include vars-light;
- @include color-vars-light;
+ @include mixvars.vars-light;
+ @include mixlight.color-vars-light;
&[data-color-scheme="light"] {
color-scheme: light;
@@ -11,8 +15,8 @@ body {
color-scheme: dark;
@media screen {
- @include vars-dark;
- @include color-vars-dark;
+ @include mixvars.vars-dark;
+ @include mixdark.color-vars-dark;
}
}
}
diff --git a/assets/stylesheets/_core.scss b/assets/stylesheets/_core.scss
index 66db5ffd6..0ba0df886 100644
--- a/assets/stylesheets/_core.scss
+++ b/assets/stylesheets/_core.scss
@@ -1,7 +1,7 @@
-@import "core/reset";
-@import "core/helpers";
-@import "core/maps";
-@import "core/vars";
-@import "core/colors";
-@import "core/colors/light";
-@import "core/colors/dark";
+@use "core/reset";
+@use "core/helpers";
+@use "core/maps";
+@use "core/vars";
+@use "core/colors";
+@use "core/colors/light";
+@use "core/colors/dark";
diff --git a/assets/stylesheets/_elements.scss b/assets/stylesheets/_elements.scss
index 7ec88c3c5..c3bf78ebb 100644
--- a/assets/stylesheets/_elements.scss
+++ b/assets/stylesheets/_elements.scss
@@ -1,4 +1,4 @@
-@import "elements/banner";
-@import "elements/grid-layout";
-@import "elements/grid";
-@import "elements/tabs";
+@use "elements/banner";
+@use "elements/grid-layout";
+@use "elements/grid";
+@use "elements/tabs";
diff --git a/assets/stylesheets/_pages.scss b/assets/stylesheets/_pages.scss
index bbaa65e46..4ac6d3445 100644
--- a/assets/stylesheets/_pages.scss
+++ b/assets/stylesheets/_pages.scss
@@ -1,4 +1,4 @@
-@import "pages/landing";
-@import "pages/swift-evolution";
-@import "pages/packages";
-@import "pages/download";
+@use "pages/landing";
+@use "pages/swift-evolution";
+@use "pages/packages";
+@use "pages/download";
diff --git a/assets/stylesheets/_screen.scss b/assets/stylesheets/_screen.scss
index 21a74c098..ee5926ed2 100644
--- a/assets/stylesheets/_screen.scss
+++ b/assets/stylesheets/_screen.scss
@@ -1,3 +1,5 @@
+@use './core/_helpers' as mixhelpers;
+
*,
*:before,
*:after {
@@ -291,7 +293,7 @@ h2.header-with-anchor {
& a,
& > span {
- @include nav-link-style;
+ @include mixhelpers.nav-link-style;
padding: 0.5em;
}
}
@@ -414,7 +416,7 @@ h2.header-with-anchor {
& a,
& > span {
- @include nav-link-style;
+ @include mixhelpers.nav-link-style;
}
}
}
@@ -513,8 +515,14 @@ footer[role="contentinfo"] {
margin-left: 1em;
float: right;
- &.twitter {
- background-image: url("/assets/images/icon-twitter.svg");
+ &.x {
+ background-image: url("/assets/images/icon-x.svg");
+ }
+ &.mastodon {
+ background-image: url("/assets/images/icon-mastodon.svg");
+ }
+ &.bluesky {
+ background-image: url("/assets/images/icon-bluesky.svg");
}
&.feed {
@@ -1108,7 +1116,7 @@ article {
margin-bottom: var(--content-margin-bottom);
input {
- @include visuallyhidden;
+ @include mixhelpers.visuallyhidden;
appearance: none;
}
}
@@ -1139,7 +1147,7 @@ article {
}
.visuallyhidden {
- @include visuallyhidden();
+ @include mixhelpers.visuallyhidden();
}
.stage {
diff --git a/assets/stylesheets/application.scss b/assets/stylesheets/application.scss
index ac03e5c0b..ecad74507 100644
--- a/assets/stylesheets/application.scss
+++ b/assets/stylesheets/application.scss
@@ -2,11 +2,11 @@
layout: source
---
-@import "core";
-@import "colors";
-@import "syntax";
-@import "screen";
-@import "elements";
-@import "mobile";
-@import "pages";
-@import "print";
+@use "core";
+@use "colors";
+@use "syntax";
+@use "screen";
+@use "elements";
+@use "mobile";
+@use "pages";
+@use "print";
diff --git a/assets/stylesheets/core/_colors.scss b/assets/stylesheets/core/_colors.scss
index 9f17c7673..59dd877bc 100644
--- a/assets/stylesheets/core/_colors.scss
+++ b/assets/stylesheets/core/_colors.scss
@@ -1,3 +1,5 @@
+@use './_maps' as funmaps;
+
$base-colors: (
swift-orange: (
light: #f05138,
@@ -86,7 +88,7 @@ $base-colors: (
);
@function base-color($keys...) {
- @return map-deep-get($base-colors, $keys);
+ @return funmaps.map-deep-get($base-colors, $keys);
}
@function dark-color($name) {
diff --git a/assets/stylesheets/core/_maps.scss b/assets/stylesheets/core/_maps.scss
index 479a2c275..0b240e119 100644
--- a/assets/stylesheets/core/_maps.scss
+++ b/assets/stylesheets/core/_maps.scss
@@ -1,3 +1,6 @@
+@use 'sass:meta';
+@use 'sass:map';
+
/// Returns the value associated with a keypath in a map, or a default value if
/// no value is associated with it.
///
@@ -33,7 +36,7 @@
@if (not $map or not is-map($map)) {
$map: ();
}
- $map: map-get($map, $key);
+ $map: map.get($map, $key);
}
@return if($map, $map, $default);
}
@@ -44,5 +47,5 @@
/// @returns {Boolean}
////
@function is-map($map) {
- @return type-of($map) == map;
+ @return meta.type-of($map) == map;
}
diff --git a/assets/stylesheets/core/colors/_dark.scss b/assets/stylesheets/core/colors/_dark.scss
index b07b32afc..bb7db4f32 100644
--- a/assets/stylesheets/core/colors/_dark.scss
+++ b/assets/stylesheets/core/colors/_dark.scss
@@ -1,27 +1,30 @@
+@use 'sass:color';
+@use '../_colors' as funcolors;
+
@mixin color-vars-dark() {
--color-nav-background: var(--color-fill-tertiary);
- --color-nav-rule: #{dark-color(fill-gray-tertiary)};
- --color-active-menu-group: #{light-color(fill-tertiary)};
- --color-active-nav-item: #{dark-color(swift-orange)};
- --color-fill: #{dark-color(fill)};
- --color-fill-secondary: #{dark-color(fill-secondary)};
- --color-fill-tertiary: #{dark-color(fill-tertiary)};
- --color-fill-quaternary: #{dark-color(fill-quaternary)};
- --color-fill-blue: #{dark-color(fill-blue)};
- --color-fill-gray: #{dark-color(fill-gray)};
- --color-fill-gray-secondary: #{dark-color(fill-gray-secondary)};
- --color-fill-green-secondary: #{dark-color(fill-green-secondary)};
- --color-fill-orange-secondary: #{dark-color(fill-orange-secondary)};
- --color-fill-red-secondary: #{dark-color(fill-red-secondary)};
- --color-figure-blue: #{dark-color(figure-blue)};
- --color-figure-gray: #{dark-color(figure-gray)};
- --color-figure-gray-secondary: #{dark-color(figure-gray-secondary)};
- --color-figure-gray-tertiary: #{dark-color(figure-gray-tertiary)};
- --color-figure-green: #{dark-color(figure-green)};
- --color-figure-light-gray: #{dark-color(figure-light-gray)};
- --color-figure-orange: #{dark-color(figure-orange)};
- --color-figure-red: #{dark-color(figure-red)};
- --color-tutorials-teal: #{dark-color(tutorials-teal)};
+ --color-nav-rule: #{funcolors.dark-color(fill-gray-tertiary)};
+ --color-active-menu-group: #{funcolors.light-color(fill-tertiary)};
+ --color-active-nav-item: #{funcolors.dark-color(swift-orange)};
+ --color-fill: #{funcolors.dark-color(fill)};
+ --color-fill-secondary: #{funcolors.dark-color(fill-secondary)};
+ --color-fill-tertiary: #{funcolors.dark-color(fill-tertiary)};
+ --color-fill-quaternary: #{funcolors.dark-color(fill-quaternary)};
+ --color-fill-blue: #{funcolors.dark-color(fill-blue)};
+ --color-fill-gray: #{funcolors.dark-color(fill-gray)};
+ --color-fill-gray-secondary: #{funcolors.dark-color(fill-gray-secondary)};
+ --color-fill-green-secondary: #{funcolors.dark-color(fill-green-secondary)};
+ --color-fill-orange-secondary: #{funcolors.dark-color(fill-orange-secondary)};
+ --color-fill-red-secondary: #{funcolors.dark-color(fill-red-secondary)};
+ --color-figure-blue: #{funcolors.dark-color(figure-blue)};
+ --color-figure-gray: #{funcolors.dark-color(figure-gray)};
+ --color-figure-gray-secondary: #{funcolors.dark-color(figure-gray-secondary)};
+ --color-figure-gray-tertiary: #{funcolors.dark-color(figure-gray-tertiary)};
+ --color-figure-green: #{funcolors.dark-color(figure-green)};
+ --color-figure-light-gray: #{funcolors.dark-color(figure-light-gray)};
+ --color-figure-orange: #{funcolors.dark-color(figure-orange)};
+ --color-figure-red: #{funcolors.dark-color(figure-red)};
+ --color-tutorials-teal: #{funcolors.dark-color(tutorials-teal)};
--color-banner-foreground: rgb(240, 81, 56);
--color-banner-background: rgb(240, 81, 56, 0.1);
@@ -29,7 +32,7 @@
--color-banner-detail: rgb(240, 81, 56, 0.5);
--color-article-body-background: rgb(17, 17, 17);
- --color-button-background-active: #{dark-color(fill-blue)};
+ --color-button-background-active: #{funcolors.dark-color(fill-blue)};
--color-dropdown-background: var(--color-dropdown-dark-background);
--color-dropdown-border: var(--color-dropdown-dark-border);
--color-dropdown-option-text: var(--color-dropdown-dark-option-text);
@@ -58,8 +61,8 @@
--color-nav-stuck: var(--color-nav-dark-stuck);
--color-nav-uiblur-expanded: var(--color-nav-dark-uiblur-expanded);
--color-nav-uiblur-stuck: var(--color-nav-dark-uiblur-stuck);
- --color-runtime-preview-disabled-text: #{change-color(
- dark-color(figure-gray-secondary),
+ --color-runtime-preview-disabled-text: #{color.adjust(
+ funcolors.dark-color(figure-gray-secondary),
$alpha: 0.6
)};
--color-syntax-attributes: rgb(204, 151, 104);
diff --git a/assets/stylesheets/core/colors/_light.scss b/assets/stylesheets/core/colors/_light.scss
index 2868c2d36..cc6ea7852 100644
--- a/assets/stylesheets/core/colors/_light.scss
+++ b/assets/stylesheets/core/colors/_light.scss
@@ -1,27 +1,30 @@
+@use 'sass:color';
+@use '../_colors' as funcolors;
+
@mixin color-vars-light() {
--color-nav-background: var(--color-fill-secondary);
--color-nav-rule: rgb(230, 230, 230);
- --color-active-menu-group: #{dark-color(fill-tertiary)};
- --color-active-nav-item: #{light-color(swift-orange)};
- --color-fill: #{light-color(fill)};
- --color-fill-secondary: #{light-color(fill-secondary)};
- --color-fill-tertiary: #{light-color(fill-tertiary)};
- --color-fill-quaternary: #{light-color(fill-quaternary)};
- --color-fill-blue: #{light-color(fill-blue)};
- --color-fill-gray: #{light-color(fill-gray)};
- --color-fill-gray-secondary: #{light-color(fill-gray-secondary)};
- --color-fill-green-secondary: #{light-color(fill-green-secondary)};
- --color-fill-orange-secondary: #{light-color(fill-orange-secondary)};
- --color-fill-red-secondary: #{light-color(fill-red-secondary)};
- --color-figure-blue: #{light-color(figure-blue)};
- --color-figure-gray: #{light-color(figure-gray)};
- --color-figure-gray-secondary: #{light-color(figure-gray-secondary)};
- --color-figure-gray-tertiary: #{light-color(figure-gray-tertiary)};
- --color-figure-green: #{light-color(figure-green)};
- --color-figure-light-gray: #{light-color(figure-light-gray)};
- --color-figure-orange: #{light-color(figure-orange)};
- --color-figure-red: #{light-color(figure-red)};
- --color-tutorials-teal: #{light-color(tutorials-teal)};
+ --color-active-menu-group: #{funcolors.dark-color(fill-tertiary)};
+ --color-active-nav-item: #{funcolors.light-color(swift-orange)};
+ --color-fill: #{funcolors.light-color(fill)};
+ --color-fill-secondary: #{funcolors.light-color(fill-secondary)};
+ --color-fill-tertiary: #{funcolors.light-color(fill-tertiary)};
+ --color-fill-quaternary: #{funcolors.light-color(fill-quaternary)};
+ --color-fill-blue: #{funcolors.light-color(fill-blue)};
+ --color-fill-gray: #{funcolors.light-color(fill-gray)};
+ --color-fill-gray-secondary: #{funcolors.light-color(fill-gray-secondary)};
+ --color-fill-green-secondary: #{funcolors.light-color(fill-green-secondary)};
+ --color-fill-orange-secondary: #{funcolors.light-color(fill-orange-secondary)};
+ --color-fill-red-secondary: #{funcolors.light-color(fill-red-secondary)};
+ --color-figure-blue: #{funcolors.light-color(figure-blue)};
+ --color-figure-gray: #{funcolors.light-color(figure-gray)};
+ --color-figure-gray-secondary: #{funcolors.light-color(figure-gray-secondary)};
+ --color-figure-gray-tertiary: #{funcolors.light-color(figure-gray-tertiary)};
+ --color-figure-green: #{funcolors.light-color(figure-green)};
+ --color-figure-light-gray: #{funcolors.light-color(figure-light-gray)};
+ --color-figure-orange: #{funcolors.light-color(figure-orange)};
+ --color-figure-red: #{funcolors.light-color(figure-red)};
+ --color-tutorials-teal: #{funcolors.light-color(tutorials-teal)};
--color-banner-foreground: rgb(222, 75, 52);
--color-banner-background: rgb(222, 75, 52, 0.1);
@@ -51,13 +54,13 @@
--color-badge-default: var(--color-figure-light-gray);
--color-badge-beta: var(--color-figure-gray-tertiary);
--color-badge-deprecated: var(--color-figure-orange);
- --color-badge-dark-default: #{dark-color(figure-light-gray)};
- --color-badge-dark-beta: #{dark-color(figure-gray-tertiary)};
- --color-badge-dark-deprecated: #{dark-color(figure-orange)};
+ --color-badge-dark-default: #{funcolors.dark-color(figure-light-gray)};
+ --color-badge-dark-beta: #{funcolors.dark-color(figure-gray-tertiary)};
+ --color-badge-dark-deprecated: #{funcolors.dark-color(figure-orange)};
--color-button-background: var(--color-fill-blue);
- --color-button-background-active: #{light-color(figure-blue)};
+ --color-button-background-active: #{funcolors.light-color(figure-blue)};
--color-button-background-hover: var(--color-figure-blue);
- --color-button-text: #{light-color(fill)};
+ --color-button-text: #{funcolors.light-color(fill)};
--color-call-to-action-background: var(--color-fill-secondary);
--color-changes-added: var(--color-figure-light-gray);
--color-changes-added-hover: var(--color-figure-light-gray);
@@ -73,17 +76,14 @@
--color-code-collapsible-text: var(--color-figure-gray-tertiary);
--color-code-plain: var(--color-figure-gray);
--color-content-table-content-color: var(--color-fill-secondary);
- --color-dropdown-background: #{transparentize(light-color(fill), 0.2)};
- --color-dropdown-border: #{light-color(fill-gray)};
- --color-dropdown-option-text: #{light-color(figure-gray-secondary)};
- --color-dropdown-text: #{light-color(figure-gray)};
- --color-dropdown-dark-background: #{transparentize(light-color(fill), 0.9)};
- --color-dropdown-dark-border: #{transparentize(
- light-color(fill-gray-tertiary),
- 0.8
- )};
- --color-dropdown-dark-option-text: #{dark-color(figure-gray-secondary)};
- --color-dropdown-dark-text: #{dark-color(figure-gray)};
+ --color-dropdown-background: #{color.adjust(funcolors.light-color('fill'), $alpha: -0.2)};
+ --color-dropdown-border: #{funcolors.light-color(fill-gray)};
+ --color-dropdown-option-text: #{funcolors.light-color(figure-gray-secondary)};
+ --color-dropdown-text: #{funcolors.light-color(figure-gray)};
+ --color-dropdown-dark-background: #{color.adjust(funcolors.light-color('fill'), $alpha: -0.9)};
+ --color-dropdown-dark-border: #{color.adjust(funcolors.light-color('fill'), $alpha: -0.8)};
+ --color-dropdown-dark-option-text: #{funcolors.dark-color(figure-gray-secondary)};
+ --color-dropdown-dark-text: #{funcolors.dark-color(figure-gray)};
--color-eyebrow: var(--color-figure-gray-secondary);
--color-focus-border-color: var(--color-fill-blue);
--color-focus-color: rgba(0, 125, 250, 0.6);
@@ -94,75 +94,75 @@
--color-generic-modal-background: var(--color-fill);
--color-grid: var(--color-fill-gray);
--color-header-text: var(--color-figure-gray);
- --color-hero-eyebrow: #{dark-color(figure-gray-secondary)};
+ --color-hero-eyebrow: #{funcolors.dark-color(figure-gray-secondary)};
--color-link: var(--color-figure-blue);
--color-loading-placeholder-background: var(--color-fill);
- --color-nav-color: #{light-color(figure-gray-tertiary)};
- --color-nav-current-link: #{change-color(
- light-color(figure-gray),
+ --color-nav-color: #{funcolors.light-color(figure-gray-tertiary)};
+ --color-nav-current-link: #{color.adjust(
+ funcolors.light-color(figure-gray),
$alpha: 0.6
)};
- --color-nav-expanded: #{light-color(fill)};
- --color-nav-hierarchy-collapse-background: #{light-color(fill-gray-tertiary)};
- --color-nav-hierarchy-collapse-borders: #{dark-color(figure-gray-secondary)};
- --color-nav-hierarchy-item-borders: #{dark-color(figure-gray-secondary)};
- --color-nav-keyline: #{change-color(light-color(figure-gray), $alpha: 0.2)};
- --color-nav-link-color: #{light-color(figure-gray)};
- --color-nav-link-color-hover: #{light-color(figure-blue)};
- --color-nav-outlines: #{light-color(fill-gray)};
- // --color-nav-rule: #{change-color(light-color(fill-gray-tertiary), $alpha: 0.5)};
- --color-nav-solid-background: #{light-color(fill)};
- --color-nav-sticking-expanded-keyline: #{change-color(
- light-color(figure-gray),
+ --color-nav-expanded: #{funcolors.light-color(fill)};
+ --color-nav-hierarchy-collapse-background: #{funcolors.light-color(fill-gray-tertiary)};
+ --color-nav-hierarchy-collapse-borders: #{funcolors.dark-color(figure-gray-secondary)};
+ --color-nav-hierarchy-item-borders: #{funcolors.dark-color(figure-gray-secondary)};
+ --color-nav-keyline: #{color.adjust(funcolors.light-color(figure-gray), $alpha: 0.2)};
+ --color-nav-link-color: #{funcolors.light-color(figure-gray)};
+ --color-nav-link-color-hover: #{funcolors.light-color(figure-blue)};
+ --color-nav-outlines: #{funcolors.light-color(fill-gray)};
+ // --color-nav-rule: #{color.adjust(funcolors.light-color(fill-gray-tertiary), $alpha: 0.5)};
+ --color-nav-solid-background: #{funcolors.light-color(fill)};
+ --color-nav-sticking-expanded-keyline: #{color.adjust(
+ funcolors.light-color(figure-gray),
$alpha: 0.1
)};
- --color-nav-stuck: #{change-color(light-color(fill), $alpha: 0.9)};
- --color-nav-uiblur-expanded: #{change-color(light-color(fill), $alpha: 0.9)};
- --color-nav-uiblur-stuck: #{change-color(light-color(fill), $alpha: 0.7)};
+ --color-nav-stuck: #{color.adjust(funcolors.light-color(fill), $alpha: 0.9)};
+ --color-nav-uiblur-expanded: #{color.adjust(funcolors.light-color(fill), $alpha: 0.9)};
+ --color-nav-uiblur-stuck: #{color.adjust(funcolors.light-color(fill), $alpha: 0.7)};
--color-nav-root-subhead: var(--color-tutorials-teal);
- --color-nav-dark-border-top-color: #{change-color(
- light-color(fill),
+ --color-nav-dark-border-top-color: #{color.adjust(
+ funcolors.light-color(fill),
$alpha: 0.4
)};
- --color-nav-dark-color: #{dark-color(figure-gray-tertiary)};
- --color-nav-dark-current-link: #{change-color(
- dark-color(figure-gray),
+ --color-nav-dark-color: #{funcolors.dark-color(figure-gray-tertiary)};
+ --color-nav-dark-current-link: #{color.adjust(
+ funcolors.dark-color(figure-gray),
$alpha: 0.6
)};
- --color-nav-dark-expanded: #{dark-color(fill-tertiary)};
- --color-nav-dark-hierarchy-collapse-background: #{dark-color(
+ --color-nav-dark-expanded: #{funcolors.dark-color(fill-tertiary)};
+ --color-nav-dark-hierarchy-collapse-background: #{funcolors.dark-color(
fill-gray-tertiary
)};
- --color-nav-dark-hierarchy-collapse-borders: #{light-color(
+ --color-nav-dark-hierarchy-collapse-borders: #{funcolors.light-color(
figure-gray-secondary
)};
- --color-nav-dark-hierarchy-item-borders: #{dark-color(fill-gray-tertiary)};
- --color-nav-dark-keyline: #{change-color(
- dark-color(fill-gray-tertiary),
+ --color-nav-dark-hierarchy-item-borders: #{funcolors.dark-color(fill-gray-tertiary)};
+ --color-nav-dark-keyline: #{color.adjust(
+ funcolors.dark-color(fill-gray-tertiary),
$alpha: 0.95
)};
- --color-nav-dark-link-color: #{dark-color(figure-gray)};
- --color-nav-dark-link-color-hover: #{dark-color(figure-blue)};
- --color-nav-dark-outlines: #{dark-color(fill-gray)};
- --color-nav-dark-rule: #{dark-color(fill-gray)};
- --color-nav-dark-solid-background: #{dark-color(fill)};
- --color-nav-dark-sticking-expanded-keyline: #{change-color(
- dark-color(fill-gray-tertiary),
+ --color-nav-dark-link-color: #{funcolors.dark-color(figure-gray)};
+ --color-nav-dark-link-color-hover: #{funcolors.dark-color(figure-blue)};
+ --color-nav-dark-outlines: #{funcolors.dark-color(fill-gray)};
+ --color-nav-dark-rule: #{funcolors.dark-color(fill-gray)};
+ --color-nav-dark-solid-background: #{funcolors.dark-color(fill)};
+ --color-nav-dark-sticking-expanded-keyline: #{color.adjust(
+ funcolors.dark-color(fill-gray-tertiary),
$alpha: 0.7
)};
- --color-nav-dark-stuck: #{change-color(dark-color(fill-tertiary), $alpha: 0.9)};
- --color-nav-dark-uiblur-expanded: #{change-color(
- dark-color(fill-tertiary),
+ --color-nav-dark-stuck: #{color.adjust(funcolors.dark-color(fill-tertiary), $alpha: 0.9)};
+ --color-nav-dark-uiblur-expanded: #{color.adjust(
+ funcolors.dark-color(fill-tertiary),
$alpha: 0.9
)};
- --color-nav-dark-uiblur-stuck: #{change-color(
- dark-color(fill-tertiary),
+ --color-nav-dark-uiblur-stuck: #{color.adjust(
+ funcolors.dark-color(fill-tertiary),
$alpha: 0.7
)};
- --color-nav-dark-root-subhead: #{dark-color(tutorials-teal)};
+ --color-nav-dark-root-subhead: #{funcolors.dark-color(tutorials-teal)};
--color-runtime-preview-background: var(--color-fill-tertiary);
- --color-runtime-preview-disabled-text: #{change-color(
- light-color(figure-gray-secondary),
+ --color-runtime-preview-disabled-text: #{color.adjust(
+ funcolors.light-color(figure-gray-secondary),
$alpha: 0.6
)};
--color-runtime-preview-text: var(--color-figure-gray-secondary);
@@ -171,7 +171,7 @@
--color-step-caption: var(--color-figure-gray-secondary);
--color-step-focused: var(--color-figure-light-gray);
--color-step-text: var(--color-figure-gray-secondary);
- --color-svg-icon: #{light-color(figure-gray-secondary)};
+ --color-svg-icon: #{funcolors.light-color(figure-gray-secondary)};
--color-syntax-attributes: rgb(148, 113, 0);
--color-syntax-characters: rgb(39, 42, 216);
--color-syntax-comments: rgb(112, 127, 140);
@@ -208,19 +208,19 @@
--color-tutorial-navbar-dropdown-background: var(--color-fill);
--color-tutorial-navbar-dropdown-border: var(--color-fill-gray);
--color-tutorial-quiz-border-active: var(--color-figure-blue);
- --color-tutorials-overview-background: #{dark-color(fill-secondary)};
- --color-tutorials-overview-content: #{dark-color(figure-gray)};
- --color-tutorials-overview-content-alt: #{dark-color(figure-gray)};
- --color-tutorials-overview-eyebrow: #{dark-color(figure-gray-secondary)};
- --color-tutorials-overview-icon: #{dark-color(figure-light-gray)};
- --color-tutorials-overview-link: #{dark-color(figure-blue)};
- --color-tutorials-overview-navigation-link: #{dark-color(
+ --color-tutorials-overview-background: #{funcolors.dark-color(fill-secondary)};
+ --color-tutorials-overview-content: #{funcolors.dark-color(figure-gray)};
+ --color-tutorials-overview-content-alt: #{funcolors.dark-color(figure-gray)};
+ --color-tutorials-overview-eyebrow: #{funcolors.dark-color(figure-gray-secondary)};
+ --color-tutorials-overview-icon: #{funcolors.dark-color(figure-light-gray)};
+ --color-tutorials-overview-link: #{funcolors.dark-color(figure-blue)};
+ --color-tutorials-overview-navigation-link: #{funcolors.dark-color(
figure-gray-secondary
)};
- --color-tutorials-overview-navigation-link-active: #{dark-color(figure-gray)};
- --color-tutorials-overview-navigation-link-hover: #{dark-color(figure-gray)};
- --color-tutorial-hero-text: #{dark-color(figure-gray)};
- --color-tutorial-hero-background: #{dark-color(fill)};
+ --color-tutorials-overview-navigation-link-active: #{funcolors.dark-color(figure-gray)};
+ --color-tutorials-overview-navigation-link-hover: #{funcolors.dark-color(figure-gray)};
+ --color-tutorial-hero-text: #{funcolors.dark-color(figure-gray)};
+ --color-tutorial-hero-background: #{funcolors.dark-color(fill)};
--color-evolution-secondary-fill: var(--color-figure-light-gray);
--color-term-normal: var(--color-text);
diff --git a/assets/stylesheets/elements/_grid.scss b/assets/stylesheets/elements/_grid.scss
index fb2d1fd59..f9ebfb8c1 100644
--- a/assets/stylesheets/elements/_grid.scss
+++ b/assets/stylesheets/elements/_grid.scss
@@ -9,10 +9,12 @@
background-color: var(--color-fill-secondary);
border: 1px solid var(--color-fill-tertiary);
border-radius: var(--border-radius);
-
+ box-sizing: border-box;
+
padding: 1rem;
display: flex;
flex-direction: column;
+ overflow: hidden;
@media (prefers-contrast: more) {
background-color: transparent;
@@ -77,7 +79,7 @@
}
// Button typically embedded in a grid-level-1
-a.cta-secondary {
+a.cta-secondary, [class^="language-"] button {
background-color: var(--color-fill-tertiary);
border: 1px solid var(--color-fill-quaternary);
border-radius: var(--border-radius);
@@ -99,7 +101,7 @@ a.cta-secondary {
&:hover {
color: var(--color-link);
background-color: var(--color-fill-quaternary);
-
+
text-decoration: none;
@media (prefers-contrast: more) {
@@ -112,3 +114,22 @@ a.cta-secondary {
content: " ↗";
}
}
+
+div.highlight {
+ position: relative;
+
+ &:hover button {
+ display: block;
+ }
+}
+
+[class^="language-"] button {
+ cursor: pointer;
+ padding: 0.1rem 0.4rem;
+ font-size: 0.8rem;
+ position: absolute;
+ right: 0.4rem;
+ top: 0.4rem;
+ margin: 0;
+ display: none;
+}
diff --git a/contributing/_contributing-code.md b/contributing/_contributing-code.md
index 44b3d6140..c68a06b25 100644
--- a/contributing/_contributing-code.md
+++ b/contributing/_contributing-code.md
@@ -116,64 +116,98 @@ Swift 项目采用*小型、渐进式的变更*作为其首选的开发模式。
### 代码审查
-Swift 项目高度依赖代码审查来提高软件质量：
+Swift 项目严重依赖代码审查来提高软件质量：
-* 所有开发者的所有重要变更在提交到仓库之前都必须经过审查。较小的变更（或开发者拥有该组件的变更）可以在提交后进行审查。
+* 所有开发者进行的所有重要变更在提交到仓库之前都必须经过审查。较小的变更（或开发者拥有组件的变更）可以在提交后进行审查。
* 代码审查在 GitHub 上进行（通过对拉取请求或提交的评论），并反映在相关项目的提交邮件列表中。
-* 负责代码变更的开发者也负责进行所有必要的审查相关的变更。
+* 负责代码变更的开发者也负责进行所有必要的与审查相关的更改。
-代码审查可以是一个迭代过程，直到变更准备好提交为止。在变更发送审查后，它需要明确的批准才能提交。不要假定默认批准或通过设置截止日期来请求对补丁的主动反对。
+代码审查可以是一个迭代过程，持续到变更准备好提交为止。在变更发送出去审查后，在提交之前需要明确的批准。不要假设默许批准或通过设置截止日期来请求对补丁的主动反对。
-有时代码审查会花费比你希望更长的时间，特别是对于较大的功能。以下是一些加快审查时间的公认方法：
+有时代码审查可能需要比你希望的时间更长，特别是对于较大的功能。以下是一些加快补丁审查时间的公认方法：
-* **审查其他人的变更。**如果你帮助别人，每个人都会更愿意为你做同样的事。善意是我们的货币。
-* **将你的变更分成多个较小的变更。**你的变更越小，有人快速查看它的可能性就越大。
-* **催促变更。**如果很紧急，说明为什么尽快合并这个变更很重要，并每隔几天催促一次。如果不紧急，通常的礼貌催促频率是一周一次。记住，你是在请求其他专业开发者的宝贵时间。
+* **审查其他人的变更。** 如果你帮助他人，每个人都会更愿意为你做同样的事情。善意是我们的货币。
+* **将你的变更拆分为多个较小的变更。** 变更越小，有人快速查看它的可能性就越高。
+* **提醒变更。** 如果很紧急，提供为什么尽快落地这个变更很重要的原因，并每隔几天提醒一次。如果不紧急，通常的礼貌提醒频率是一周一次。记住，你是在请求其他专业开发者的宝贵时间。
-请注意，任何人都欢迎审查和提供反馈，但只有对仓库有提交权限的人才能批准它。
+请注意，任何人都可以审查和提供关于变更的反馈，但只有对仓库有提交权限的人才能批准它。
### 测试
-开发者需要为修复的任何错误和添加的任何新功能创建测试用例，并将它们与变更一起提交。
+开发者需要为任何修复的错误和添加的新功能创建测试用例，并将它们与变更一起贡献。
* 所有功能和回归测试用例都添加到适当的测试目录中---例如，`swift/test` 目录。
-* 在最接近实际功能的抽象层次编写测试用例。例如，如果是 Swift 语言功能，就用 Swift 编写；如果是 SIL 优化，就用 SIL 编写。
-* 尽可能减少测试用例，特别是对于回归测试。将整个失败的程序放入 `swift/test` 是不可接受的，因为这会降低所有开发者的测试速度。请保持简短。
+* 在最接近实际功能的抽象级别编写测试用例。例如，如果是 Swift 语言功能，用 Swift 编写；如果是 SIL 优化，用 SIL 编写。
+* 尽可能减少测试用例，特别是对于回归测试。将整个失败的程序放入 `swift/test` 是不可接受的，因为这会使所有开发者的测试变慢。请保持它们简短。
### 质量
-人们依靠 Swift 来创建他们的生产软件。这意味着 Swift 中的一个错误可能会导致成千上万，甚至数百万开发者的产品出现错误。因此，Swift 项目保持着高质量标准。在提交到主开发分支之前，任何变更必须满足的最低质量标准包括：
+人们依赖 Swift 来创建他们的生产软件。这意味着 Swift 中的错误可能会导致数千甚至数百万开发者的产品出现错误。因此，Swift 项目对质量保持高标准。任何变更在提交到主开发分支之前必须满足的最低质量标准包括：
-1. 代码必须在至少一个平台上编译时没有错误或警告。
-2. 错误修复和新功能必须包含测试用例以发现任何未来的回归，或者包含说明为什么测试用例不切实际的理由。
+1. 代码必须至少在一个平台上编译时没有错误或警告。
+2. 错误修复和新功能必须包含测试用例以确定任何未来的回归，或包含为什么测试用例不切实际的理由。
3. 代码必须通过适当的测试套件---例如，Swift 编译器中的 `swift/test` 和 `swift/validation-test` 测试套件。
此外，提交者负责解决变更可能在未来造成的任何问题。这种责任意味着你可能需要更新你的变更以：
* 确保代码在所有主要平台上都能干净地编译。
* 修复在其他测试套件中发现的任何正确性回归。
-* 修复任何主要性能回归。
+* 修复任何重大性能回归。
* 修复下游 Swift 工具中的任何性能或正确性回归。
* 修复使用 Swift 的客户代码中出现的任何性能或正确性回归。
* 解决由于你的变更而在错误跟踪器中出现的任何错误。
-我们希望这些问题在提交之前就能解决，但我们理解不可能对每个提交都进行所有这些测试。我们的持续集成（CI）基础设施通常会发现这些问题。我们建议在接下来的一天里关注 CI 基础设施以查找回归。如果包含你的提交的一组提交导致失败，CI 基础设施会直接给你发送电子邮件。你应该检查这些消息，看看是否是你的错，如果是，就修复这些问题。
+我们更希望这些问题在提交之前得到处理，但我们理解不可能对每个提交都测试所有这些。我们的持续集成（CI）基础设施通常会找到这些问题。我们建议在接下来的日子里关注 CI 基础设施以寻找回归。如果包含你的提交的一组提交导致了失败，CI 基础设施会直接给你发邮件。你应该检查这些消息，看看它们是否是你的问题，如果是，修复这个破坏。
-明显违反这些质量标准的提交可能会被还原，特别是当变更阻碍其他开发者取得进展时。在问题解决后，欢迎开发者重新提交变更。
+明显违反这些质量标准的提交可能会被还原，特别是当变更阻止其他开发者取得进展时。在问题修复后，开发者可以重新提交变更。
-### 提交权限
+### 贡献者阶梯
-提交权限授予给有提交高质量变更记录的贡献者。如果你想获得提交权限，请向[代码所有者列表](mailto:code-owners@forums.swift.org)发送电子邮件，说明你想使用的 GitHub 用户名，并列出 5 个被接受且无需修改的非平凡拉取请求。
+这个贡献者阶梯定义了你在为 GitHub 上的 Swift 做贡献时可能获得的角色。每个角色都有相关的特权，这需要与贡献者社区建立信任。我们认识到 Swift 有许多不同类型的贡献者，我们感谢每一个！每个参与开源 Swift 项目的人都是*贡献者*：这可以是编写代码、在论坛上回答问题、报告或分类错误，或参与 Swift 演进过程。
-一旦你获得了提交权限，你将能够向托管 Swift.org 项目的所有 GitHub 仓库提交代码。要验证你的提交权限是否有效，请进行测试提交（例如，更改注释或添加空行）。以下政策适用于具有提交权限的用户：
+当你通过为 GitHub 上的 Swift 做贡献而攀登贡献者阶梯时，你获得新的特权，但也获得了信任和责任，你被期望履行这些责任。如果贡献者违反这种信任和责任，核心团队可能会给他们通知，并在重复违规时撤销他们的级别。我们相信一个健康的社区，并希望这种行动永远不会是必要的。
-* 你被授予对 Swift 所有部分的批准后提交权限。要获得批准，创建一个拉取请求。当拉取请求被批准后，你可以自己合并它。
+#### 成员
-* 你可以在未经事先批准的情况下提交明显的变更。社区期望你运用良好的判断。例如，还原明显损坏的补丁、更正代码注释和其他小变更。
+*成员*已经多次为 Swift 做出了建设性的贡献。这个角色在整个组织中持有，成为*成员*允许你在 GitHub 上的 swiftlang 组织中的所有仓库触发 CI。
-* 你可以在未经批准的情况下向你已贡献或被分配责任的 Swift 部分提交变更。这些提交不得破坏构建。这是一个"信任但验证"的政策，此类提交在提交后进行审查。
+- 要求
+ - 对 Swift 项目做出多次建设性的贡献。这可以是 PR 的形式、参与 Swift 论坛、提交有价值的议题、对它们进行分类，或类似的形式。
+- 特权
+ - 能够触发 CI 测试
+ - 在你的 GitHub 个人资料上显示你在 swiftlang 组织中的成员身份
+- 提名
+ - 如果你想成为成员，请发送一封电子邮件到[代码所有者列表](mailto:code-owners@forums.swift.org)，包括你的贡献和你想要使用的 GitHub 用户名
+- 成长
+ - 展示你建设性地使用特权并继续贡献以获得提交权限。
-多次违反这些政策或单次严重违反可能导致提交权限被撤销。即使有提交权限，你的变更仍然需要经过[代码审查](#code-review)。当然，我们也鼓励你审查其他人的变更。
+#### 提交权限
+
+提交权限授予给有提交高质量变更记录的贡献者。如果你想获得提交权限，请发送一封电子邮件到[代码所有者列表](mailto:code-owners@forums.swift.org)，包括你想要使用的 GitHub 用户名和 5 个被接受且无需修改的非平凡拉取请求的列表。
+
+一旦你被授予提交权限，你将能够提交到所有托管 Swift.org 项目的 GitHub 仓库。要验证你的提交权限是否有效，请进行一个测试提交（例如，更改注释或添加空行）。以下政策适用于具有提交权限的用户：
+
+* 你被授予对 Swift 所有部分的批准后提交权限。要获得批准，创建拉取请求。当拉取请求被批准时，你可以自己合并它。
+
+* 你可以在不首先获得批准的情况下提交明显的变更。社区期望你使用良好的判断力。例子包括还原明显损坏的补丁、更正代码注释和其他小变更。
+
+* 你被允许在没有批准的情况下提交变更到你已贡献或已被分配责任的 Swift 部分。此类提交不得破坏构建。这是一个"信任但验证"的政策，这种性质的提交在提交后会被审查。
+
+多次违反这些政策或一次严重违反可能导致提交权限被撤销。即使有提交权限，你的变更仍然需要经过[代码审查](#code-review)。当然，我们也鼓励你审查其他人的变更。
+
+#### 代码所有者
+
+代码所有者是被分配到 Swift 项目特定领域的个人，他们的主要职责是代码质量。Swift 项目由许多子项目组成，包括 Swift 标准库、LLDB 调试器的扩展和 Swift 包管理器等。每个子项目都会被分配一个代码所有者。代码所有者然后努力让所有贡献得到审查，收集社区的反馈，并将批准的补丁引导到产品中。
+
+任何人都可以审查一段代码，我们欢迎所有感兴趣的人进行代码审查。代码审查程序不是由中央、全局政策决定的。相反，这个过程由每个代码所有者定义。
+
+任何活跃并证明自己有价值的社区成员都可以通过发帖到论坛来提供成为代码所有者，或被另一个成员提名。如果其他贡献者同意，项目负责人将做出任命并将新所有者的名字添加到代码所有者文件中。这个职位完全是自愿的，可以随时辞职。
+
+当前代码所有者的列表可以在父 Swift 源代码树的根目录中的 `CODE_OWNERS.txt` 文件中找到。我们还维护一个邮件组，这样你可以[发送电子邮件](mailto:code-owners@forums.swift.org)给所有代码所有者。
+
+对于 Swift 的成功来说，可能没有什么比强大、投入的代码所有者更重要了。我们都欠他们尊重、感激和任何我们能提供的帮助。
+
+每个贡献者都有责任将自己的名字添加到项目根目录的 `CONTRIBUTORS.txt` 文件中，并维护联系信息。如果你是在你公司的保护伞下做贡献，请添加你公司的信息，不要也将自己列为额外的版权持有者。
[community]: /community "Swift.org 社区概述"
[get_started]: /getting-started/ "如何设置你自己的 Swift 版本"
\ No newline at end of file
diff --git a/docker-compose.yaml b/docker-compose.yaml
index be16897f9..c2e42a19b 100644
--- a/docker-compose.yaml
+++ b/docker-compose.yaml
@@ -9,13 +9,11 @@
# SPDX-License-Identifier: Apache-2.0
# usage:
-# docker-compose run build
+# docker compose run build
#
-# docker-compose up website
+# docker compose up website
#
-version: "2"
-
services:
docker-setup:
diff --git a/documentation/articles/getting-started-with-vscode-swift.md b/documentation/articles/getting-started-with-vscode-swift.md
index f547c649e..5f2b69b3e 100644
--- a/documentation/articles/getting-started-with-vscode-swift.md
+++ b/documentation/articles/getting-started-with-vscode-swift.md
@@ -30,7 +30,7 @@ The Swift extension is designed to support the following projects:
[Getting Started Guide on Swift.org](/getting-started/).
2. Download and install [Visual Studio Code](https://code.visualstudio.com/Download).
3. Install the Swift extension from the
- [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang)
+ [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode)
or directly from within the VS Code extensions pane.
diff --git a/documentation/continuous-integration/index.md b/documentation/continuous-integration/index.md
index e9ecbb820..e1b55f573 100644
--- a/documentation/continuous-integration/index.md
+++ b/documentation/continuous-integration/index.md
@@ -4,7 +4,7 @@ layout: page
title: Swift Continuous Integration
---
-The Swift project follows an [incremental development model](../contributing/#contributing_code), and utilizes continuous integration (CI) testing of changes in pull requests before merging as a core tool for maintaining project stability. The system produces the snapshot builds posted on swift.org, and runs tests against active branches. It is also used as part of the review process to run tests against pull requests before committing them.
+The Swift project follows an [incremental development model](/contributing/#contributing-code), and utilizes continuous integration (CI) testing of changes in pull requests before merging as a core tool for maintaining project stability. The system produces the snapshot builds posted on swift.org, and runs tests against active branches. It is also used as part of the review process to run tests against pull requests before committing them.
## Configuration
@@ -46,7 +46,7 @@ If there are issues found during testing, you will get a link to the details of
-It is expected that changes meet the [quality standards](../contributing/#quality) for the Swift project before they are committed to the development branch, and you are responsible for fixing problems found by your changes. If your changes break builds or tests on the development or release branches, you will receive email notification.
+It is expected that changes meet the [quality standards](/contributing/#quality) for the Swift project before they are committed to the development branch, and you are responsible for fixing problems found by your changes. If your changes break builds or tests on the development or release branches, you will receive email notification.
## Community Involvement
diff --git a/documentation/cxx-interop/index.md b/documentation/cxx-interop/index.md
index dec9d631e..a1f06a9e8 100644
--- a/documentation/cxx-interop/index.md
+++ b/documentation/cxx-interop/index.md
@@ -492,7 +492,8 @@ because they return a reference that points into the `Forest` object.
#### Virtual Member Functions
-Currently virtual member functions are not available in Swift.
+Virtual methods of C++ value types cannot be called from Swift. This is similar
+to C++, where you can only call virtual methods on a pointer or a reference.
#### Static Member Functions
@@ -1254,6 +1255,14 @@ object.doSomething()
// `object` will be released here.
```
+### Inheritance and Virtual Member Functions
+
+Similar to value types, casting an instance of a derived reference type to a
+base reference type, or vice versa, is not yet supported by Swift.
+
+If a reference type has virtual methods, you can call those methods from Swift.
+This includes pure virtual methods.
+
#### Exposing C++ Shared Reference Types back from Swift
C++ can call into Swift APIs that take or return C++ Shared Reference Types. Objects of these types are always created on the C++ side,
@@ -1276,11 +1285,6 @@ The C++ caller of this function is responsible for releasing the object.
The `SWIFT_UNSAFE_REFERENCE` annotation macro has the same effect as `SWIFT_IMMORTAL_REFERENCE`
annotation macro. However, it communicates different semantics: the type is intended to be used unsafely, rather than living for the duration of the program.
-### Unique Reference Types
-
-Unique reference types, such as types passed around by `std::unique_ptr` are
-not yet supported by Swift.
-
## Using C++ Standard Library from Swift
This section describes how to import the C++ standard library, and how
@@ -1982,6 +1986,11 @@ that are outlined in the documentation above.
This section lists the recent changes made to this reference guide.
+**2025-04-07**
+
+- C++ virtual methods of reference types are now available in Swift.
+- `std::unique_ptr` is now supported in Swift.
+
**2024-08-12**
- Added several customization macros from `
+ Comparison between our legacy service and new Swift-based one.
+
diff --git a/install/linux/index.md b/install/linux/index.md
index 3e9f83993..b5a4b9ccc 100644
--- a/install/linux/index.md
+++ b/install/linux/index.md
@@ -4,5 +4,4 @@ title: 安装 Swift
---
{% include install/_os_tabs.md linux="true" %}
-
{% include install/_linux_platforms_tabs.md %}
diff --git a/install/linux/swiftly/index.md b/install/linux/swiftly/index.md
new file mode 100644
index 000000000..e45dbf3ae
--- /dev/null
+++ b/install/linux/swiftly/index.md
@@ -0,0 +1,69 @@
+---
+layout: page
+title: Getting Started with Swiftly on Linux
+---
+
+Download swiftly for [Linux (Intel)](https://download.swift.org/swiftly/linux/swiftly-{{ site.data.builds.swiftly_release.version }}-x86_64.tar.gz), or [Linux (ARM)](https://download.swift.org/swiftly/linux/swiftly-{{ site.data.builds.swiftly_release.version }}-aarch64.tar.gz).
+
+```
+curl -O https://download.swift.org/swiftly/linux/swiftly-{{ site.data.builds.swiftly_release.version }}-$(uname -m).tar.gz
+```
+
+You can verify the integrity of the archive using the PGP signature. This will download the signature, install the swift.org signatures into your keychain, and verify the signature.
+
+```
+curl https://www.swift.org/keys/all-keys.asc | gpg --import -
+curl -O https://download.swift.org/swiftly/linux/swiftly-{{ site.data.builds.swiftly_release.version }}-$(uname -m).tar.gz.sig
+gpg --verify swiftly-{{ site.data.builds.swiftly_release.version }}-$(uname -m).tar.gz.sig swiftly-{{ site.data.builds.swiftly_release.version }}-$(uname -m).tar.gz
+```
+
+Extract the archive.
+
+```
+tar -zxf swiftly-{{ site.data.builds.swiftly_release.version }}-$(uname -m).tar.gz
+```
+
+Run the following command in your terminal, to configure swiftly for your account, and automatically download the latest swift toolchain.
+
+```
+./swiftly init
+```
+
+Note: You can set the SWIFTLY_HOME_DIR and SWIFTLY_BIN_DIR environment variables to customize your install location.
+
+Your current shell may need some additional steps to update your session. Follow the guidance at the end of the installation for a smooth install experience, such as sourcing the environment file, and rehashing your shell's PATH.
+
+There can be certain packages that need to be installed on your system so that the Swift toolchain can function. The swiftly initialization routine will show you how to install any missing packages.
+
+Now that swiftly and swift are installed, you can access the `swift` command from the latest Swift release:
+
+```
+swift --version
+--
+Swift version {{ site.data.builds.swift_releases.last.name }} (swift-{{ site.data.builds.swift_releases.last.name }}-RELEASE)
+Target: x86_64-unknown-linux-gnu
+```
+
+Or, you can install (and use) another swift release:
+
+```
+swiftly install --use 5.10
+swift --version
+--
+Swift version 5.10 (swift-5.10-RELEASE)
+Target: x86_64-unknown-linux-gnu
+```
+
+There's also an option to install the latest snapshot release and get access to the latest features:
+
+```
+swiftly install --use main-snapshot
+```
+
+Check for updates to swiftly and install them by running the self-update command:
+
+```
+swiftly self-update
+```
+
+You can discover more about swiftly in the [documentation](https://www.swift.org/swiftly/documentation/swiftlydocs/)
diff --git a/install/linux/tarball/index.md b/install/linux/tarball/index.md
index 38a947b3a..89a741d2c 100644
--- a/install/linux/tarball/index.md
+++ b/install/linux/tarball/index.md
@@ -103,4 +103,4 @@ $ tar xzf swift--.tar.gz
$ export PATH=/path/to/usr/bin:"${PATH}"
```
-现在您可以执行 `swift` 命令来运行 REPL 或构建 Swift 项目。
+现在您可以执行 `swift repl` 命令来运行 REPL 执行 `swift build` 来构建 Swift 项目。
diff --git a/install/macos/index.md b/install/macos/index.md
index e64556cfc..8e8cd31a1 100644
--- a/install/macos/index.md
+++ b/install/macos/index.md
@@ -5,27 +5,45 @@ title: 安装 Swift
{% include install/_os_tabs.md macos="true" %}
-## 最新发布版本 (Swift {{ site.data.builds.swift_releases.last.name }})
-
-
-
+## 最新版本
+
-
+
Swiftly
++ 要从 Swift.org 下载工具链，请使用 Swiftly 工具链安装程序。Swift.org 工具链支持静态 Linux SDK，包含实验性功能如嵌入式 Swift 和 WebAssembly 支持。 +
+在终端中运行以下命令：
++curl -O https://download.swift.org/swiftly/darwin/swiftly.pkg && \ +installer -pkg swiftly.pkg -target CurrentUserHomeDirectory && \ +~/.swiftly/bin/swiftly init --quiet-shell-followup && \ +. ~/.swiftly/env.sh && \ +hash -r +许可证：Apache-2.0
+ 安装说明 +
+ -
Xcode
- 下载最新版本的Xcode，其中包含最新的Swift工具链。 + 要为 Apple 平台开发 Swift 应用，请下载最新版本的 Xcode，它会定期更新最新的 Swift 工具链。
安装 Xcode
+ - {{ person.name }} +{%- if person.affiliation -%} +, {{ person.affiliation }} +{% endif %} +{% if person.handle %} +(@{{person.handle}}) +{% endif %} + +{% endfor %} +
-
+
-
{% include install/_static_sdk_release.md %}
+Your current shell may need some additional steps to update your session. Follow the guidance at the end of the installation for a smooth install experience, such as sourcing the environment file, and rehashing your shell's PATH.
+
+
+Now that swiftly and swift are installed, you can access the `swift` command from the latest Swift release:
+
+```
+swift --version
+--
+Apple Swift version {{ site.data.builds.swift_releases.last.name }} (swift-{{ site.data.builds.swift_releases.last.name }}-RELEASE)
+Target: arm64-apple-macosx15.0
+```
+
+Or, you can install (and use) another swift release:
+
+```
+swiftly install --use 5.10
+swift --version
+--
+Apple Swift version 5.10 (swift-5.10-RELEASE)
+Target: arm64-apple-macosx15.0
+```
+
+There's also an option to install the latest snapshot release and get access to the latest features:
+
+```
+swiftly install --use main-snapshot
+```
+
+Check for updates to swiftly and install them by running the self-update command:
+
+```
+swiftly self-update
+```
+
+You can discover more about swiftly in the [documentation](https://www.swift.org/swiftly/documentation/swiftlydocs/)
diff --git a/openapi/TestSwiftOrgClient/.gitignore b/openapi/TestSwiftOrgClient/.gitignore
new file mode 100644
index 000000000..06b994824
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/.gitignore
@@ -0,0 +1,3 @@
+.build
+.swiftpm
+Package.resolved
diff --git a/openapi/TestSwiftOrgClient/Package.swift b/openapi/TestSwiftOrgClient/Package.swift
new file mode 100644
index 000000000..384c5ab1a
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/Package.swift
@@ -0,0 +1,38 @@
+// swift-tools-version: 6.0
+import PackageDescription
+
+let clientNames: [String] = [
+ "swiftorgClient",
+ "downloadswiftorgClient",
+]
+
+let package = Package(
+ name: "TestSwiftOrgClient",
+ platforms: [
+ .macOS(.v13),
+ ],
+ dependencies: [
+ .package(url: "https://github.com/apple/swift-openapi-generator", from: "1.7.0"),
+ .package(url: "https://github.com/apple/swift-openapi-runtime", from: "1.8.0"),
+ .package(url: "https://github.com/apple/swift-openapi-urlsession", from: "1.0.0"),
+ ],
+ targets: [
+ .target(
+ name: "Shared",
+ path: "Shared"
+ )
+ ] + clientNames.map { name in
+ .executableTarget(
+ name: name,
+ dependencies: [
+ "Shared",
+ .product(name: "OpenAPIRuntime", package: "swift-openapi-runtime"),
+ .product(name: "OpenAPIURLSession", package: "swift-openapi-urlsession"),
+ ],
+ path: name,
+ plugins: [
+ .plugin(name: "OpenAPIGenerator", package: "swift-openapi-generator"),
+ ]
+ )
+ }
+)
diff --git a/openapi/TestSwiftOrgClient/README.md b/openapi/TestSwiftOrgClient/README.md
new file mode 100644
index 000000000..362ba3e5b
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/README.md
@@ -0,0 +1,54 @@
+# Test Swift.org client
+
+This simple Swift package contains a Swift HTTP Client that can be used to test the Swift.org API.
+
+It is generated from the OpenAPI document of Swift.org and generated using Swift OpenAPI Generator.
+
+## Usage
+
+You can run it either against the Swift.org API or against a locally running API.
+
+By default, the tool runs against the production Swift.org APIs.
+
+Run against production using:
+```
+SWIFTORG_SERVER_NAME=prod swift run swiftorgClient
+DOWNLOADSWIFTORG_SERVER_NAME=prod swift run downloadswiftorgClient
+```
+
+Run against a locally running server using:
+```
+SWIFTORG_SERVER_NAME=local swift run swiftorgClient
+```
+
+The exact server URLs are defined in the OpenAPI document.
+
+If the tool detects a deserialization error, possibly because the OpenAPI document does not correctly parse the returned data, it will exit with a non-zero exit code.
+
+If all test cases run successfully, the tool exits with 0.
+
+Sample output:
+
+```
+% SWIFTORG_SERVER_NAME=prod swift run swiftorgClient
+Testing SwiftOrg API at https://www.swift.org/api/v1...
+✅ listReleases
+✅ listDevToolchains(main, amazonlinux2)
+✅ listDevToolchains(main, centos7)
+✅ listDevToolchains(main, macos)
+✅ listDevToolchains(main, ubi9)
+✅ listDevToolchains(main, ubuntu2004)
+✅ listDevToolchains(main, ubuntu2204)
+✅ listDevToolchains(main, windows10)
+✅ listDevToolchains(6.0, amazonlinux2)
+✅ listDevToolchains(6.0, centos7)
+✅ listDevToolchains(6.0, macos)
+✅ listDevToolchains(6.0, ubi9)
+✅ listDevToolchains(6.0, ubuntu2004)
+✅ listDevToolchains(6.0, ubuntu2204)
+✅ listDevToolchains(6.0, windows10)
+✅ listStaticSDKDevToolchains(main)
+✅ listStaticSDKDevToolchains(6.0)
+% DOWNLOADSWIFTORG_SERVER_NAME=prod swift run downloadswiftorgClient
+✅ listProposals
+```
diff --git a/openapi/TestSwiftOrgClient/Shared/Tester.swift b/openapi/TestSwiftOrgClient/Shared/Tester.swift
new file mode 100644
index 000000000..9743b61df
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/Shared/Tester.swift
@@ -0,0 +1,46 @@
+//===----------------------------------------------------------------------===//
+//
+// This source file is part of the Swift.org open source project
+//
+// Copyright (c) 2025 Apple Inc. and the Swift.org project authors
+// Licensed under Apache License v2.0
+//
+// See LICENSE.txt for license information
+// See CONTRIBUTORS.txt for the list of Swift.org project authors
+//
+// SPDX-License-Identifier: Apache-2.0
+//
+//===----------------------------------------------------------------------===//
+
+import Foundation
+
+package struct Test: Sendable {
+ package var name: String
+ package var work: @Sendable () async throws -> Void
+
+ package init(name: String, work: @Sendable @escaping () async throws -> Void) {
+ self.name = name
+ self.work = work
+ }
+}
+
+package struct Tester {
+ package static func run(_ tests: [Test]) async throws {
+ var results: [(String, Error?)] = []
+ func runTest(_ test: Test) async {
+ do {
+ try await test.work()
+ results.append((test.name, nil))
+ print("✅ \(test.name)")
+ } catch {
+ results.append((test.name, error))
+ print("❌ \(test.name): \(String(describing: error))")
+ }
+ }
+ for test in tests {
+ await runTest(test)
+ }
+ let failed = results.contains(where: { $0.1 != nil })
+ exit(failed ? 1 : 0)
+ }
+}
diff --git a/openapi/TestSwiftOrgClient/downloadswiftorgClient/Issue847Workaround.swift b/openapi/TestSwiftOrgClient/downloadswiftorgClient/Issue847Workaround.swift
new file mode 100644
index 000000000..e7ac54ee4
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/downloadswiftorgClient/Issue847Workaround.swift
@@ -0,0 +1,39 @@
+//===----------------------------------------------------------------------===//
+//
+// This source file is part of the Swift.org open source project
+//
+// Copyright (c) 2025 Apple Inc. and the Swift.org project authors
+// Licensed under Apache License v2.0
+//
+// See LICENSE.txt for license information
+// See CONTRIBUTORS.txt for the list of Swift.org project authors
+//
+// SPDX-License-Identifier: Apache-2.0
+//
+//===----------------------------------------------------------------------===//
+
+import OpenAPIRuntime
+import HTTPTypes
+import Foundation
+
+// Workaround for issue: https://github.com/swiftlang/swift-org-website/issues/847
+struct Issue847WorkaroundMiddleware: ClientMiddleware {
+ func intercept(
+ _ request: HTTPRequest,
+ body: HTTPBody?,
+ baseURL: URL,
+ operationID: String,
+ next: (HTTPRequest, HTTPBody?, URL) async throws -> (HTTPResponse, HTTPBody?)
+ ) async throws -> (HTTPResponse, HTTPBody?) {
+ var (response, responseBody) = try await next(request, body, baseURL)
+ guard
+ operationID == "listProposals" &&
+ response.status.code == 200 &&
+ response.headerFields[.contentType] == "application/octet-stream"
+ else {
+ return (response, responseBody)
+ }
+ response.headerFields[.contentType] = "application/json"
+ return (response, responseBody)
+ }
+}
diff --git a/openapi/TestSwiftOrgClient/downloadswiftorgClient/Tool.swift b/openapi/TestSwiftOrgClient/downloadswiftorgClient/Tool.swift
new file mode 100644
index 000000000..62beccc96
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/downloadswiftorgClient/Tool.swift
@@ -0,0 +1,60 @@
+//===----------------------------------------------------------------------===//
+//
+// This source file is part of the Swift.org open source project
+//
+// Copyright (c) 2025 Apple Inc. and the Swift.org project authors
+// Licensed under Apache License v2.0
+//
+// See LICENSE.txt for license information
+// See CONTRIBUTORS.txt for the list of Swift.org project authors
+//
+// SPDX-License-Identifier: Apache-2.0
+//
+//===----------------------------------------------------------------------===//
+
+import OpenAPIURLSession
+import Foundation
+import Shared
+
+enum DownloadSwiftOrgServerName: String {
+ case prod
+ case local
+}
+
+@main
+struct Tool {
+ static func main() async throws {
+ let serverURL: URL
+ if
+ let name = ProcessInfo.processInfo.environment["DOWNLOADSWIFTORG_SERVER_NAME"],
+ let serverName = DownloadSwiftOrgServerName(rawValue: name)
+ {
+ switch serverName {
+ case .prod:
+ serverURL = try Servers.Server1.url()
+ case .local:
+ serverURL = try Servers.Server2.url()
+ }
+ } else {
+ serverURL = try Servers.Server1.url()
+ }
+
+ print("Testing download.swift.org API at \(serverURL.absoluteString)...")
+
+ let client = Client(
+ serverURL: serverURL,
+ transport: URLSessionTransport(),
+ middlewares: [
+ Issue847WorkaroundMiddleware(),
+ ]
+ )
+
+ let tests: [Test] = [
+ .init(
+ name: "listProposals",
+ work: { _ = try await client.listProposals().ok.body.json }
+ ),
+ ]
+ try await Tester.run(tests)
+ }
+}
diff --git a/openapi/TestSwiftOrgClient/downloadswiftorgClient/openapi-generator-config.yaml b/openapi/TestSwiftOrgClient/downloadswiftorgClient/openapi-generator-config.yaml
new file mode 120000
index 000000000..4477f4bbd
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/downloadswiftorgClient/openapi-generator-config.yaml
@@ -0,0 +1 @@
+../openapi-generator-config.yaml
\ No newline at end of file
diff --git a/openapi/TestSwiftOrgClient/downloadswiftorgClient/openapi.yaml b/openapi/TestSwiftOrgClient/downloadswiftorgClient/openapi.yaml
new file mode 120000
index 000000000..e07e01573
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/downloadswiftorgClient/openapi.yaml
@@ -0,0 +1 @@
+../../downloadswiftorg.yaml
\ No newline at end of file
diff --git a/openapi/TestSwiftOrgClient/openapi-generator-config.yaml b/openapi/TestSwiftOrgClient/openapi-generator-config.yaml
new file mode 100644
index 000000000..efb77df22
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/openapi-generator-config.yaml
@@ -0,0 +1,6 @@
+generate:
+ - types
+ - client
+namingStrategy: idiomatic
+nameOverrides:
+ 'x86_64': 'x86_64'
diff --git a/openapi/TestSwiftOrgClient/swiftorgClient/Tool.swift b/openapi/TestSwiftOrgClient/swiftorgClient/Tool.swift
new file mode 100644
index 000000000..6f6e13195
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/swiftorgClient/Tool.swift
@@ -0,0 +1,103 @@
+//===----------------------------------------------------------------------===//
+//
+// This source file is part of the Swift.org open source project
+//
+// Copyright (c) 2025 Apple Inc. and the Swift.org project authors
+// Licensed under Apache License v2.0
+//
+// See LICENSE.txt for license information
+// See CONTRIBUTORS.txt for the list of Swift.org project authors
+//
+// SPDX-License-Identifier: Apache-2.0
+//
+//===----------------------------------------------------------------------===//
+
+import OpenAPIURLSession
+import Foundation
+import Shared
+
+enum SwiftOrgServerName: String {
+ case prod
+ case local
+}
+
+@main
+struct Tool {
+ static func main() async throws {
+ let serverURL: URL
+ if
+ let name = ProcessInfo.processInfo.environment["SWIFTORG_SERVER_NAME"],
+ let serverName = SwiftOrgServerName(rawValue: name)
+ {
+ switch serverName {
+ case .prod:
+ serverURL = try Servers.Server1.url()
+ case .local:
+ serverURL = try Servers.Server2.url()
+ }
+ } else {
+ serverURL = try Servers.Server1.url()
+ }
+
+ print("Testing swift.org API at \(serverURL.absoluteString)...")
+
+ let client = Client(
+ serverURL: serverURL,
+ transport: URLSessionTransport()
+ )
+
+ var tests: [Test] = [
+ .init(
+ name: "listReleases",
+ work: { _ = try await client.listReleases().ok.body.json }
+ ),
+ ]
+ for branch in Components.Schemas.KnownSourceBranch.allCases {
+ for platform in Components.Schemas.KnownPlatformIdentifier.allCases {
+ tests.append(
+ .init(
+ name: "listDevToolchains(\(branch.rawValue), \(platform.rawValue))",
+ work: {
+ _ = try await client.listDevToolchains(.init(
+ path: .init(
+ branch: .init(value1: branch),
+ platform: .init(value1: platform)
+ )
+ )).ok.body.json
+ }
+ )
+ )
+ }
+ }
+ for branch in Components.Schemas.KnownSourceBranch.allCases {
+ tests.append(
+ .init(
+ name: "listStaticSDKDevToolchains(\(branch.rawValue))",
+ work: {
+ _ = try await client.listStaticSDKDevToolchains(.init(path: .init(branch: .init(value1: branch)))).ok.body.json
+ }
+ )
+ )
+ }
+ tests.append(
+ .init(
+ name: "getCurrentSwiftlyRelease",
+ work: {
+ _ = try await client.getCurrentSwiftlyRelease().ok.body.json
+ }
+ )
+ )
+ for level in Components.Schemas.SSWGIncubationFilter.allCases {
+ tests.append(
+ .init(
+ name: "listSSWGIncubatedPackages(\(level.rawValue))",
+ work: {
+ _ = try await client.listSSWGIncubatedPackages(.init(path: .init(filter: level))).ok.body.json
+ }
+ )
+ )
+ }
+
+ try await Tester.run(tests)
+ }
+}
diff --git a/openapi/TestSwiftOrgClient/swiftorgClient/openapi-generator-config.yaml b/openapi/TestSwiftOrgClient/swiftorgClient/openapi-generator-config.yaml
new file mode 120000
index 000000000..4477f4bbd
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/swiftorgClient/openapi-generator-config.yaml
@@ -0,0 +1 @@
+../openapi-generator-config.yaml
\ No newline at end of file
diff --git a/openapi/TestSwiftOrgClient/swiftorgClient/openapi.yaml b/openapi/TestSwiftOrgClient/swiftorgClient/openapi.yaml
new file mode 120000
index 000000000..543a8bae5
--- /dev/null
+++ b/openapi/TestSwiftOrgClient/swiftorgClient/openapi.yaml
@@ -0,0 +1 @@
+../../swiftorg.yaml
\ No newline at end of file
diff --git a/openapi/downloadswiftorg.yaml b/openapi/downloadswiftorg.yaml
new file mode 100644
index 000000000..ec444e9f0
--- /dev/null
+++ b/openapi/downloadswiftorg.yaml
@@ -0,0 +1,322 @@
+openapi: 3.0.3
+info:
+ title: download.swift.org API
+ description: API for the download.swift.org hostname.
+ version: 1.0.0
+servers:
+ - url: https://download.swift.org
+ description: The production server.
+ - url: http://127.0.0.1:4000/api/v1
+ description: A local deployment.
+tags:
+ - name: Evolution
+ description: Information about the Swift evolution process.
+paths:
+ /swift-evolution/v1/evolution.json:
+ get:
+ summary: List all proposals
+ description: Retrieve a list of all Swift Evolution proposals.
+ operationId: listProposals
+ tags:
+ - Evolution
+ responses:
+ '200':
+ description: A list of proposals.
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/schemas/ProposalListSnapshot'
+components:
+ schemas:
+ ProposalListSnapshot:
+ type: object
+ properties:
+ schemaVersion:
+ type: string
+ description: The version of the schema used for this data.
+ example: '1.0.0'
+ toolVersion:
+ type: string
+ description: The version of the tool used to generate this data.
+ example: '0.1.0'
+ commit:
+ type: string
+ description: The commit hash of the data.
+ example: 'be37f35a0f06ab07dc6c84b3676833260cb86ddd'
+ creationDate:
+ type: string
+ format: date-time
+ description: The creation date of the data.
+ example: '2024-11-08T16:50:22Z'
+ implementationVersions:
+ type: array
+ items:
+ $ref: '#/components/schemas/SwiftVersion'
+ description: The known versions of Swift for the returned proposals.
+ proposals:
+ type: array
+ items:
+ $ref: '#/components/schemas/Proposal'
+ required:
+ - schemaVersion
+ - toolVersion
+ - commit
+ - creationDate
+ - implementationVersions
+ - proposals
+ SwiftVersion:
+ type: string
+ description: A version of Swift.
+ example: '6.1'
+ ProposalState:
+ anyOf:
+ - $ref: '#/components/schemas/KnownProposalState'
+ - type: string
+ description: The raw state, a fallback for when an unknown state is received.
+ KnownProposalState:
+ type: string
+ enum:
+ - accepted
+ - activeReview
+ - implemented
+ - previewing
+ - rejected
+ - returnedForRevision
+ - withdrawn
+ description: |-
+ The current state of the proposal.
+
+ This is distinct from `ProposalState` to allow parsing unknown states.
+ Parsing unknown states is important to avoid a new state causing a major API break.
+ example: accepted
+ ProposalStatus:
+ type: object
+ description: The status of a proposal.
+ properties:
+ state:
+ $ref: '#/components/schemas/ProposalState'
+ version:
+ $ref: '#/components/schemas/SwiftVersion'
+ start:
+ type: string
+ description: The start date of a review.
+ example: '2024-10-24T00:00:00Z'
+ end:
+ type: string
+ description: The end date of a review.
+ example: '2024-11-07T00:00:00Z'
+ required:
+ - state
+ ProposalDiscussion:
+ type: object
+ properties:
+ name:
+ type: string
+ description: The name of the discussion.
+ example: 'pitch'
+ link:
+ type: string
+ format: uri
+ description: URL to the discussion.
+ example: 'https://forums.swift.org/t/pitch-swift-backtracing-api/62741'
+ required:
+ - name
+ - link
+ ProposalPerson:
+ type: object
+ properties:
+ name:
+ type: string
+ description: The name of the person.
+ example: 'Swift Dev123'
+ link:
+ type: string
+ description: URL to the person's GitHub profile.
+ example: 'https://github.com/swiftdev123'
+ required:
+ - name
+ TrackingIssue:
+ type: object
+ description: An issue tracking work on a proposal.
+ properties:
+ id:
+ type: string
+ description: The ID of the tracking issue.
+ example: 'apple/swift#46493'
+ link:
+ type: string
+ format: uri
+ description: URL to the tracking bug.
+ example: 'https://github.com/apple/swift/issues/46493'
+ required:
+ - id
+ - link
+ KnownProposalDiagnosticKind:
+ type: string
+ description: |-
+ The kind of diagnostic.
+
+ This is distinct from `ProposalDiagnosticKind` to allow parsing unknown kinds.
+ Parsing unknown kinds is important to avoid a new kind causing a major API break.
+ enum:
+ - warning
+ - error
+ ProposalDiagnosticKind:
+ anyOf:
+ - $ref: '#/components/schemas/KnownProposalDiagnosticKind'
+ - type: string
+ description: The raw kind, a fallback for when an unknown kind is received.
+ ProposalDiagnostic:
+ type: object
+ description: A diagnostic found on a proposal.
+ properties:
+ code:
+ type: integer
+ description: A numeric code of the diagnostic.
+ example: 0
+ kind:
+ $ref: '#/components/schemas/ProposalDiagnosticKind'
+ message:
+ type: string
+ description: A diagnostic message.
+ example: 'Missing or invalid dates for a review period.'
+ suggestion:
+ type: string
+ description: A suggested fix for the diagnostic.
+ example: 'Update the start and end fields in the proposal state.'
+ required:
+ - code
+ - kind
+ - message
+ - suggestion
+ ProposalCodeChangeType:
+ anyOf:
+ - $ref: '#/components/schemas/KnownProposalCodeChangeType'
+ - type: string
+ description: The raw type, a fallback for when an unknown type is received.
+ KnownProposalCodeChangeType:
+ type: string
+ enum:
+ - pull
+ - commit
+ description: |-
+ The code change kind.
+
+ This is distinct from `ProposalCodeChangeType` to allow parsing unknown types.
+ Parsing unknown types is important to avoid a new type causing a major API break.
+ example: pull
+ ProposalCodeChange:
+ type: object
+ description: A code change associated with a proposal.
+ properties:
+ account:
+ type: string
+ description: The GitHub organization name of the repository containing the code change.
+ example: 'swiftlang'
+ repository:
+ type: string
+ description: The GitHub name of the repository containing the code change.
+ example: 'swift'
+ id:
+ type: string
+ description: The identifier of the code change in the repository.
+ example: '76636'
+ type:
+ $ref: '#/components/schemas/ProposalCodeChangeType'
+ required:
+ - account
+ - repository
+ - id
+ - type
+ ProposalID:
+ type: string
+ pattern: 'SE-\d{4}'
+ description: The unique identifier of the proposal.
+ example: 'SE-0001'
+ ProposalUpcomingFeatureFlag:
+ type: object
+ description: An upcoming feature flag that enables the proposal's behavior.
+ properties:
+ flag:
+ type: string
+ description: The name of the feature flag, passed to the Swift tools.
+ example: 'DynamicActorIsolation'
+ required:
+ - flag
+ Proposal:
+ type: object
+ description: A proposed change to the Swift project.
+ properties:
+ id:
+ $ref: '#/components/schemas/ProposalID'
+ title:
+ type: string
+ description: The title of the proposal.
+ example: 'Swift Backtrace API'
+ summary:
+ type: string
+ description: A brief summary of the proposal.
+ example: |-
+ This year we are improving the usability of Swift for command line and server-side
+ development by adding first-class support for backtraces to Swift.
+ status:
+ $ref: '#/components/schemas/ProposalStatus'
+ authors:
+ type: array
+ description: A list of the authors of the proposal.
+ items:
+ $ref: '#/components/schemas/ProposalPerson'
+ reviewManagers:
+ type: array
+ description: A list of the review managers of the proposal.
+ items:
+ $ref: '#/components/schemas/ProposalPerson'
+ link:
+ type: string
+ description: File name to the proposal document.
+ example: '0419-backtrace-api.md'
+ discussions:
+ type: array
+ description: Links to the related discussions on the Swift Forums.
+ items:
+ $ref: '#/components/schemas/ProposalDiscussion'
+ trackingBugs:
+ type: array
+ description: A list of tracking issues for the proposal.
+ items:
+ $ref: '#/components/schemas/TrackingIssue'
+ implementation:
+ type: array
+ description: A list of the code changes associated with this proposal.
+ items:
+ $ref: '#/components/schemas/ProposalCodeChange'
+ upcomingFeatureFlag:
+ $ref: '#/components/schemas/ProposalUpcomingFeatureFlag'
+ sha:
+ type: string
+ description: 'TODO - what does this represent?'
+ example: '86cfc386995a0b8c68528728545d1d981fccbc2e'
+ previousProposalIDs:
+ type: array
+ description: A list of IDs that this proposal was associated with in the past.
+ items:
+ $ref: '#/components/schemas/ProposalID'
+ warnings:
+ type: array
+ description: A list of warnings associated with the proposal.
+ items:
+ $ref: '#/components/schemas/ProposalDiagnostic'
+ errors:
+ type: array
+ description: A list of errors associated with the proposal.
+ items:
+ $ref: '#/components/schemas/ProposalDiagnostic'
+ required:
+ - id
+ - title
+ - summary
+ - status
+ - authors
+ - reviewManagers
+ - link
+ - sha
diff --git a/openapi/index.md b/openapi/index.md
new file mode 100644
index 000000000..ce02401b9
--- /dev/null
+++ b/openapi/index.md
@@ -0,0 +1,28 @@
+---
+layout: page-wide
+title: Swift.org API Documentation
+---
+
+The Swift.org website provides HTTP APIs that vends information about toolchain releases, Swift evolution proposals, and more.
+
+The APIs are documented using [OpenAPI](https://www.openapis.org).
+
+## Browsable API documentation
+
+Rendered documentation of the APIs can be browsed [here](./openapi.html).
+
+## Downloadable OpenAPI documents
+
+The machine-readable document can be downloaded from the following URLs:
+
+- swift.org API: [`https://swift.org/openapi/swiftorg.yaml`](swiftorg.yaml)
+- download.swift.org API: [`https://swift.org/openapi/downloadswiftorg.yaml`](downloadswiftorg.yaml)
+
+## Generating a client in Swift
+
+You can generate a type-safe client from OpenAPI documents using [Swift OpenAPI Generator](https://github.com/apple/swift-openapi-generator).
+
+## Tools using the Swift.org APIs
+
+- [swiftly](https://github.com/swiftlang/swiftly)
+- [Swift Evolution](https://www.swift.org/swift-evolution/)
diff --git a/openapi/openapi.html b/openapi/openapi.html
new file mode 100644
index 000000000..af69257f8
--- /dev/null
+++ b/openapi/openapi.html
@@ -0,0 +1,56 @@
+
+
+
+
+
+
+ -
+{% for person in people %}
+