swift-syntax

510.0.2

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code.
swiftlang/swift-syntax

What's New

510.0.2

2024-05-07T16:24:18Z

Compared to 510.0.1 this release fixes compilation warnings about retroactive conformances when building swift-syntax with a Swift 6 compiler.

It also contains the following changes from 510.0.0.

New APIs

  • SyntaxStringInterpolation.appendInterpolation(_: (some SyntaxProtocol)?)

    • Description: Allows optional syntax nodes to be used inside string interpolation of syntax nodes. If the node is nil, nothing will get added to the string interpolation.
    • Pull Request: #2085
  • SyntaxCollection.index(at:)

    • Description: Returns the index of the n-th element in a SyntaxCollection. This computation is in O(n) and SyntaxCollection is not subscriptable by an integer.
    • Pull Request: #2014
  • Convenience initializer ClosureCaptureSyntax.init()

    • Description: Provides a convenience initializer for ClosureCaptureSyntax that takes a concrete name argument and automatically adds equal = TokenSyntax.equalToken() to it.
    • Issue: #1984
    • Pull Request: #2127
  • Convenience initializer EnumCaseParameterSyntax.init()

    • Description: Provides a convenience initializer for EnumCaseParameterSyntax that takes a concrete firstName value and adds colon = TokenSyntax.colonToken() automatically to it.
    • Issue: #1984
    • Pull Request: #2112
  • DiagnosticSeverity and PluginMessage.Diagnostic.Severity now have new case named remark

    • Description: Remarks are used by the Swift compiler and other tools to describe some aspect of translation that doesn't reflect correctness, but may be useful for the user. Remarks have been added to the diagnostic severity enums to align with the Swift compiler.
    • Pull Request: #2143

Deprecations

  • Leaf Node Casts

    • Description: Syntax nodes that do not act as base nodes for other syntax types have the casting methods marked as deprecated. This prevents unsafe type-casting by issuing deprecation warnings for methods that will always result in failed casts.
    • Issue: #2092
    • Pull Request: #2108
  • Same-Type Casts

    • Description: is, as, and cast overloads on SyntaxProtocol with same-type conversions are marked as deprecated. The deprecated methods emit a warning indicating the cast will always succeed.
    • Issue: #2092
    • Pull Request: #2108
  • Base Node Casts

    • Description: is, as, and cast methods on base node protocols with base-type conversions are marked as deprecated. The deprecated methods emit a warning that informs the developer that the cast will always succeed and should be done using the base node's initializer.
    • Issue: #2092
    • Pull Request: #2108
  • WildcardPatternSyntax.typeAnnotation

    • Description: typeAnnotation on WildcardPatternSyntax was a mistake. Use typeAnnotation properties on the outer constructs instead. E.g. PatternBindingListSyntax.typeAnnotation
    • Pull Request: #2393

API-Incompatible Changes

  • NoteMessage.fixItID renamed to noteID

    • Description: This was an error that it was named fixItID and should have been named noteID instead. Accesses to fixItID are deprecated and forward to noteID. Any types that conform NoteMessage it will need to be updated to provide a noteID instead of a fixItID.
    • Issue: #2261
    • Pull Request: #2264
  • DiagnosticSpec.highlight replaced by highlights

    • Description: The use of a single string highlight prevented users from asserting that a macro highlighted exactly the expected set of syntax nodes. Use of DiagnosticSpec.init(...highlight:...) is deprecated and forwards to DiagnosticSpec.init(...highlights:...). Migrating from highlight to highlights is straightforward; any uses of DiagnosticSpec.init which do not specify a highlight do not need to change, otherwise:
      • If the diagnostic highlights a single node, the highlight string should be replaced with a single element array containing the same string without any trailing trivia, e.g., highlight: "let " -> highlights: ["let"].
      • If the diagnostic highlights multiple nodes, the highlight string should be replaced with an array containing an element for each highlighted node, e.g., highlight: "struct {}" -> highlights: ["struct", "{}"].
    • Pull Request: #2213

Swift Syntax

The swift-syntax package is a set of libraries that work on a source-accurate tree representation of Swift source code, called the SwiftSyntax tree. The SwiftSyntax tree forms the backbone of Swift’s macro system – the macro expansion nodes are represented as SwiftSyntax nodes and a macro generates a SwiftSyntax tree to be inserted into the source file.

Documentation

You can read SwiftSyntax’s documentation on swiftpackageindex.com.

A great way to interactively explore the SwiftSyntax tree of a source file is https://swift-ast-explorer.com, developed by @kishikawakatsumi.

A set of example usages of swift-syntax can be found in Examples.

Releases

Releases of SwiftSyntax are aligned with corresponding language and tooling releases, for example the major version 509 of swift-syntax is aligned with Swift 5.9.

To depend on swift-syntax in a SwiftPM package, add the following to your Package.swift.

dependencies: [
  .package(url: "https://github.com/apple/swift-syntax.git", from: "<#latest swift-syntax tag#>"),
],

To add swift-syntax as a dependency of your Xcode project, go to the Package Dependencies tab of your Xcode project, click the plus button and search for https://github.com/apple/swift-syntax.git.

Reporting Issues

If you should hit any issues while using SwiftSyntax, we appreciate bug reports on GitHub Issue.

Contributing

Start contributing to SwiftSyntax see this guide for more information.

Bazel

SwiftSyntax provides an experimental Bazel build configuration, maintained by Keith Smiley. To use it you can pull the source archive from the relevant release tag into your WORKSPACE and depend on the libraries you need from the BUILD.bazel file. Each library also has an associated Library_opt target (such as SwiftSyntax_opt) which forces SwiftSyntax to always build with optimizations enabled. This may help local runtime performance at the cost of debuggability, and initial build time. Please tag any issues related to the Bazel configuration with the label "Bazel".

License

Please see LICENSE for more information.

Description

  • Swift Tools 5.7.0
View More Packages from this Author

Dependencies

  • None
Last updated: Sat Dec 21 2024 12:10:53 GMT-1000 (Hawaii-Aleutian Standard Time)