Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Diagnostic Decorator and Testing Utilities #2238

Merged

Conversation

Matejkob
Copy link
Contributor

@Matejkob Matejkob commented Sep 26, 2023

This PR is part of the efforts related to #2214.

Commit 1: Add DiagnosticDecorator Protocol, ANSIDiagnosticDecorator and BacisDiagnosticDecorator Implementations

  • Introduce a new protocol, DiagnosticDecorator, to standardize the decoration of diagnostic output.
  • Implement ANSIDiagnosticDecorator, which provides ANSI colorization and severity-based prefixes for enhanced visibility.

Commit 2: Introduce Diagnostic Testing Utilities

  • Add DiagnosticTestingUtils.swift to facilitate more effective unit testing of diagnostics.

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for splitting the PR. It makes the review a lot easier. And also thanks for the long comments, they also really help understand what’s going on.

I left a couple comments inline. On a high level, I’ve got a couple of questions:

  • What do you imagine the use case of implementing a DiagnosticDecorator to be? AFAICT ANSIDiagnosticGenerator is the only one that we currently have and that you’ll introduce in Enhancements to diagnostic formatters and testing utilities #2214 and I would prefer to not have the DiagnosticDecorator protocol abstraction unless we actually use it.
  • I would prefer to not make DiagnosticDecorator, ANSIDiagnosticDecorator public. If we do, it becomes part of the public API surface and it’s a lot harder to change in the future if we don’t want to break it.
  • AFAICT nothing is using the DiagnosticDecorator yet. I understand that you will be using it in Enhancements to diagnostic formatters and testing utilities #2214 but I think it would be good to start using it in the current implementation already unless it’s a huge amount of work. I understand that it’s more work that might seem unnecessary but it would really split Enhancements to diagnostic formatters and testing utilities #2214 into two self-contained pieces that are easier to review.

///
/// - Returns: A tuple containing:
/// - `highlightedSourceCode`: A string that represents the decorated version of the original source code snippet.
/// - `additionalHighlightedLine`: always with nil.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to return additionalHighlightedLine if it’s always nil?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is nil in this implementation because the ANSI codes are able to underline lines directly. The assumption is that in future implementations it will contain characters like ~~~ or ---.

Copy link
Member

@ahoppen ahoppen Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have a slight preference to only add additionalHighlightedLine once we actually add a diagnostic annotator that uses it, but I’m fine with keeping it as well.

My thought is just that having an API which we don’t actually test is just relatively error-prone.

Edit: And I just realized that it looks like the diagnostic formatter is even ignoring the additional line right now, which means that it’s quite confusing if we offer it on the protocol but don’t actually handle it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the Enhance diagnostic formatter to include trivia between highlight nodes thread, you mentioned the idea of changing assertSyntaxHighlightRanges to actually underline the highlighted ranges, either via DiagnosticDecorator or a custom function. I think that's a really neat idea. Given that we plan to use DiagnosticDecorator in the next PR, I'd opt for keeping it as is for now.

Tests/SwiftDiagnosticsTest/DiagnosticTestingUtils.swift Outdated Show resolved Hide resolved
Tests/SwiftDiagnosticsTest/DiagnosticTestingUtils.swift Outdated Show resolved Hide resolved
@Matejkob
Copy link
Contributor Author

Thank you for taking the time to review my PR @ahoppen ; your feedback is invaluable, and I really appreciate the time you've invested.

Addressing your concerns:

  • What do you imagine the use case of implementing a DiagnosticDecorator to be? AFAICT ANSIDiagnosticGenerator is the only one that we currently have and that you’ll introduce in Enhancements to diagnostic formatters and testing utilities #2214 and I would prefer to not have the DiagnosticDecorator protocol abstraction unless we actually use it.

The overarching vision for the DiagnosticDecorator, as well as other key components like DiagnosticsFormatter and GroupedDiagnostics in the SwiftDiagnostics package, which I have in mind, is to serve as highly customizable and modular tools. The long-term goal would be to empower end-users either by allowing them to build upon these components or by using them directly. To give you a concrete example, @pointfreeco swift-macro-testing library has already adopted the DiagnosticsFormatter. Unfortunately, they had to copy-paste the code into their project and manually adjust its implementation, even though their project depends on swift-syntax. This is hardly an ideal scenario and also illustrates the need for a more modular approach.

But it's not just about third-party implementations; we also have potential use-cases within our own ecosystem. For instance, consider the area of macro diagnostics testing. Currently, we have an assert method for macros, which, while functional, lacks advanced diagnostic capabilities. I believe there's a real opportunity here to provide the developer community with a simple yet effective tool for visualizing and debugging macro diagnostics. As we know, debugging macros can be challenging due to the compiler expansions involved, and this feature could significantly alleviate that pain.

Lastly, let's talk about the immediate benefits. We are already planning enhancements to DiagnosticsFormatter by adding missing diagnostic elements, which will require robust unit testing. Currently, those unit tests containing diagnostic's highlights are hard to read and maintain, especially when they include complicated diagnostic output expectations. Take this example:

let expectedOutput = """
  \u{001B}[0;36m1 │\u{001B}[0;0m for \u{001B}[4;39m(i\u{001B}[0;0m \u{001B}[4;39m= 🐮; i != 👩‍👩‍👦‍👦; i += 1)\u{001B}[0;0m { }
    \u{001B}[0;36m│\u{001B}[0;0m │      ╰─ \u{001B}[1;31merror: \u{001B}[1;39mexpected ')' to end tuple pattern\u{001B}[0;0m
    \u{001B}[0;36m│\u{001B}[0;0m ╰─ \u{001B}[1;31merror: \u{001B}[1;39mC-style for statement has been removed in Swift 3\u{001B}[0;0m
  """

With the decorator abstraction in place, we can create more readable and developer-friendly unit tests, as shown below:

let expectedOutput = """
  1 │ for (i = 🐮; i != 👩‍👩‍👦‍👦; i += 1) { }
    │     ~~ ~~~~~~~~~~~~~~~~~~~~~~~
    │ │      ╰─ error: expected ')' to end tuple pattern
    │ ╰─ error: C-style for statement has been removed in Swift 3

  """
  • I would prefer to not make DiagnosticDecorator, ANSIDiagnosticDecorator public. If we do, it becomes part of the public API surface and it’s a lot harder to change in the future if we don’t want to break it.

You bring up a valid concern about making DiagnosticDecorator and ANSIDiagnosticDecorator public, given that it would lock us into maintaining those APIs and limit our ability to make future changes. I completely agree with you on this. In fact, with the understanding that these APIs are likely to evolve, I've already marked DiagnosticDecorator and ANSIDiagnosticDecorator with @_spi(Testing). This should help us maintain the flexibility to adapt and refine these components as we continue to build upon them.

Great point about immediate use. I've already integrated DiagnosticDecorator into DiagnosticsFormatter to make this PR more self-contained and easier to review.

Note

Disclaimer: I want to clarify that my proposed changes stem from research, requirement gathering, and learning about the existing landscape—rather than imposing my own singular vision. I recognize the challenges in fully capturing the current and future needs for diagnostic formatters. The PRs are meant as a collaborative stepping stone, combining what I've learned, observed in other projects, and a few of my own ideas. My aim is for us to build a unified vision together, using the code I've already written as a foundation.

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for providing the detailed response. I think the overall direction is very good. I would just like to keep DiagnosticDecorator internal until we have gained some more experience with it. I think all the other comments are fairly minor.

Sources/SwiftDiagnostics/GroupedDiagnostics.swift Outdated Show resolved Hide resolved
/// - file: The file where the test is located, used for reporting failures.
/// - line: The line where the test is located, used for reporting failures.
///
/// - Returns: A ``Diagnostic`` instance populated with details from the ``DiagnosticDescriptor``, or `nil` if it fails.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of silently failing and not generating a Diagnostic for a DiagnosticDescriptor if it fails, what do you think about throwing an error instead? I think that should make it a lot clearer what’s going wrong if you write eg. a DiagnosticDescriptor with a marker that doesn’t exist in the source code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that implementing the assert function in this way would indeed make the code clearer, but I'm not entirely convinced that the end result would be more transparent to the users of this high-level API.

My primary motivation behind this implementation approach was to avoid interrupting the assertion process unnecessarily. The assertAnnotated function takes a collection of diagnosticDescriptors as an argument. I chose to return nil while also invoking XCTFail so that we could iterate over all elements, inform the user only about the missing ones, and apply the existing ones to provide as much assertion validation as possible. For instance, if only one location marker out of four is missing, the user will end up with the following result:

Screenshot 2023-10-11 at 7 18 50 PM

I believe this approach benefits end clients. If I'm not mistaken, it wouldn't work in the same way if we chose to throw an error, would it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I missed the fact that we always emitted an XCTFail if we return nil.

And I think me missing that is a reason why I would prefer to throw. My thinking is that if you are missing one of the diagnostic markers in your test input, there’s something wrong with the test case itself (not just a runtime failure) and thus early exiting is quite alright.

As it stands right now, every time I would read this code, I would wonder the same thing that I originally commented:

  • Are we silently dropping one of our test case assertions here? That seems dangerous
  • Looks at implementation/documentation: Oh, no, it’s fine we emit an XCTFail in that case.
  • Now, what was I doing originally? Needs to restore mental context after side-stepping.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You make some solid points. You got me—I'm convinced.

I'll swap out the nil and XCTFail combo for a good ol' error throw. Thanks for the nudge!

Tests/SwiftDiagnosticsTest/DiagnosticTestingUtils.swift Outdated Show resolved Hide resolved
Tests/SwiftDiagnosticsTest/DiagnosticTestingUtils.swift Outdated Show resolved Hide resolved
@Matejkob Matejkob force-pushed the annotat-source-lines-with-notes-preperations branch from 1fa1824 to 5896246 Compare October 11, 2023 17:54
/// - file: The file where the test is located, used for reporting failures.
/// - line: The line where the test is located, used for reporting failures.
///
/// - Returns: A ``Diagnostic`` instance populated with details from the ``DiagnosticDescriptor``, or `nil` if it fails.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I missed the fact that we always emitted an XCTFail if we return nil.

And I think me missing that is a reason why I would prefer to throw. My thinking is that if you are missing one of the diagnostic markers in your test input, there’s something wrong with the test case itself (not just a runtime failure) and thus early exiting is quite alright.

As it stands right now, every time I would read this code, I would wonder the same thing that I originally commented:

  • Are we silently dropping one of our test case assertions here? That seems dangerous
  • Looks at implementation/documentation: Oh, no, it’s fine we emit an XCTFail in that case.
  • Now, what was I doing originally? Needs to restore mental context after side-stepping.

@Matejkob Matejkob force-pushed the annotat-source-lines-with-notes-preperations branch 2 times, most recently from 240a0fd to 425ed9a Compare October 16, 2023 16:18
Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One really small nitpick, otherwise looks good to me 👍🏽

Tests/SwiftDiagnosticsTest/DiagnosticTestingUtils.swift Outdated Show resolved Hide resolved
@Matejkob Matejkob force-pushed the annotat-source-lines-with-notes-preperations branch 2 times, most recently from 2ac8607 to 14b3f31 Compare October 17, 2023 05:02
@ahoppen
Copy link
Member

ahoppen commented Oct 17, 2023

@swift-ci Please test

@Matejkob
Copy link
Contributor Author

CI failed with the following message:

DiagnosticsFormatter.swift:80:28: error: cannot find type 'DiagnosticDecorator' in scope

From a Swift perspective, this doesn't seem to be failing, since it's in the same module and the type is internal. Should I modify CMakeLists.txt? Is there any documentation where I can learn more about what's going on here?

@bnbarham
Copy link
Contributor

Should I modify CMakeLists.txt?

Yeah, you'll need to add all the new files to cmake as well.

Is there any documentation where I can learn more about what's going on here?

Not really. The compiler uses cmake rather than SPM to build swift-syntax (for the libraries included in the toolchain), so any new files have to be added to the relevant CMakeLists.txt.

@Matejkob Matejkob force-pushed the annotat-source-lines-with-notes-preperations branch from 14b3f31 to 0668f63 Compare October 20, 2023 07:39
@ahoppen
Copy link
Member

ahoppen commented Oct 20, 2023

@swift-ci Please test

@ahoppen
Copy link
Member

ahoppen commented Oct 20, 2023

@swift-ci Please test Windows

@ahoppen
Copy link
Member

ahoppen commented Oct 20, 2023

Test Case '-[SwiftDiagnosticsTest.GroupedDiagnosticsFormatterTests testGroupingForMacroExpansion]' failed (0.487 seconds).

@Matejkob Could you look at the failure?

This commit introduces three significant components:

1. `DiagnosticDecorator` Protocol:
  - Defines a standard interface for decorating diagnostic output in source code.
  - Design to be used by entities like `DiagnosticsFormatter` and `GroupedDiagnostics`.

2. `ANSIDiagnosticDecorator` Struct:
  - Implements the `DiagnosticDecorator` protocol.
  - Adds severity-based prefixes to diagnostic messages.
  - Supports ANSI colorization to enhance visibility and interpretation.

3. `BasicDiagnosticDecorator` Struct:
  - Implements the `DiagnosticDecorator` protocol.
  - Adds severity-based prefixes to diagnostic messages.

Also includes:
- Unit tests for `ANSIDiagnosticDecorator` in `ANSIDiagnosticDecoratorTests` and `BasicDiagnosticDecorator` in `BasicDiagnosticDecoratorTests`.

This feature enriches the diagnostic capabilities, offering customizable and visually informative feedback.
auto-merge was automatically disabled October 21, 2023 11:10

Head branch was pushed to by a user without write access

@Matejkob Matejkob force-pushed the annotat-source-lines-with-notes-preperations branch from 0668f63 to ade9844 Compare October 21, 2023 11:10
Introduces `DiagnosticTestingUtils.swift`, a utility suite designed to aid in writing unit tests for `DiagnosticsFormatter` and `GroupedDiagnostics`. Highlights include:

1. `LocationMarker` Typealias:
  - Enhances readability and precision in location identification within AST.

2. `DiagnosticDescriptor` and `NoteDescriptor` Structs:
  - Offers a robust mechanism to construct and describe diagnostics and notes for testing.

3. Simple Implementations for Protocols:
  - `SimpleNoteMessage` and `SimpleDiagnosticMessage` for streamlined testing.

4. `assertAnnotated` Function:
  - Asserts that annotated source generated from diagnostics aligns with the expected output.

This addition significantly bolsters the testing utilities, providing a comprehensive framework for ensuring accurate and effective diagnostics.
@Matejkob Matejkob force-pushed the annotat-source-lines-with-notes-preperations branch from ade9844 to 636556c Compare October 21, 2023 11:18
@Matejkob
Copy link
Contributor Author

Oops! I mistakenly committed a modified test and disabled the GroupedDiagnosticsFormatterTests test case in Xcode. Consequently, when I ran all the tests, it didn't fail. My apologies for the oversight. 🙈

@ahoppen
Copy link
Member

ahoppen commented Oct 23, 2023

No problem. Let’s try again.

@swift-ci Please test

@Matejkob
Copy link
Contributor Author

Is this the main problem /Users/ec2-user/jenkins/workspace/swift-syntax-PR-macOS/branch-main/swift/lib/LLVMPasses/ARCEntryPointBuilder.h:21:10: fatal error: 'llvm/TargetParser/Triple.h' file not found ?

@ahoppen
Copy link
Member

ahoppen commented Oct 24, 2023

Seems like an unrelated issue. Trying again.

@swift-ci Please test macOS

@ahoppen
Copy link
Member

ahoppen commented Oct 24, 2023

@swift-ci Please test Windows

@ahoppen ahoppen merged commit 0f808e7 into swiftlang:main Oct 25, 2023
3 checks passed
art-divin added a commit to art-divin/swift-syntax that referenced this pull request Nov 2, 2023
commit ebd7026
Merge: e5962c4 efbfbab
Author: Ben Barham <b.n.barham@gmail.com>
Date:   Fri Oct 27 16:04:15 2023 -0700

    Merge pull request swiftlang#2313 from bnbarham/literal-expr-parsing

    Skip parsing trailing closures after literals

commit efbfbab
Author: Ben Barham <ben_barham@apple.com>
Date:   Wed Oct 25 14:08:57 2023 -0700

    Skip parsing trailing closures after literals

    Postfix parsing should skip trailing closure if the base expression is
    a literal (which is not callable).

commit e5962c4
Merge: 18c5bce 8fb1309
Author: Sophia Poirier <2997196+sophiapoirier@users.noreply.github.com>
Date:   Thu Oct 26 15:15:30 2023 -0700

    Merge pull request swiftlang#2306 from sophiapoirier/globals_strict_concurrency_opt_out_nonisolated_unsafe

    nonisolated(unsafe) to opt out of strict concurrency static checking for global variables

commit 18c5bce
Merge: 598e191 dbb04e5
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Thu Oct 26 11:05:54 2023 -0700

    Merge pull request swiftlang#2311 from ahoppen/ahoppen/511-version-indicator

    Add a `SwiftSyntax511` version indicator module

commit 598e191
Merge: bcd4772 a5315ff
Author: Boris Bügling <bbuegling@apple.com>
Date:   Wed Oct 25 14:06:20 2023 -0700

    Merge pull request swiftlang#2312 from apple/load-unaligned

    load => loadUnaligned

commit a5315ff
Author: Boris Buegling <bbuegling@apple.com>
Date:   Wed Oct 25 11:29:53 2023 -0700

    load => loadUnaligned

    Same fix as swiftlang/swift-package-manager#6929 since the code in swift-syntax is based on what is in SwiftPM.

commit bcd4772
Merge: 48c2705 12993b0
Author: Ben Barham <b.n.barham@gmail.com>
Date:   Wed Oct 25 10:10:33 2023 -0700

    Merge pull request swiftlang#2265 from bnbarham/cast-sometimes-fails

    Casts to children of `SyntaxProtocol` are not always invalid

commit 48c2705
Merge: 0f808e7 1dc4c16
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Tue Oct 24 19:25:43 2023 -0700

    Merge pull request swiftlang#2308 from art-divin/function-compilation-optimization

    Optimized Type Checker performance in UnicodeScalarExtensions and SyntaxText

commit dbb04e5
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Tue Oct 24 18:41:32 2023 -0700

    Add a `SwiftSyntax511` version indicator module

commit 0f808e7
Merge: 8d5fab7 636556c
Author: Alex Hoppen <alex@alexhoppen.de>
Date:   Tue Oct 24 17:17:45 2023 -0700

    Merge pull request swiftlang#2238 from Matejkob/annotat-source-lines-with-notes-preperations

commit 12993b0
Author: Ben Barham <ben_barham@apple.com>
Date:   Mon Oct 23 17:29:51 2023 -0700

    Casts to children of SyntaxProtocol are not always invalid

    Update these overrides so they don't always fail.

commit 1dc4c16
Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
Date:   Mon Oct 23 22:35:34 2023 +0400

    Squashed commit of the following:

    commit 4cd9756
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Mon Oct 23 22:17:28 2023 +0400

        applied swift-format

    commit dc59e96
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Mon Oct 23 22:02:35 2023 +0400

        removed redundant variable

    commit ff95302
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Mon Oct 23 22:00:23 2023 +0400

        refactored optimization in isValidIdentifierContinuationCodePoint

    commit 5b94ec9
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Mon Oct 23 21:51:48 2023 +0400

        fixed a typo; renamed variables

    commit 7e1f23d
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Mon Oct 23 21:38:08 2023 +0400

        renamed variables in slice(of:)

    commit 3b9c1f8
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Sat Oct 21 19:45:34 2023 +0400

        removed redundant newline

    commit 83ad08c
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Sat Oct 21 19:02:13 2023 +0400

        optimized isSlice(of other: SyntaxText) -> Bool

    commit f5d0a3a
    Author: Ruslan Alikhamov <r.alikhamov@gmail.com>
    Date:   Sat Oct 21 19:02:03 2023 +0400

        optimized isValidIdentifierContinuationCodePoint

commit 8d5fab7
Merge: f8be751 46c39ad
Author: Ben Barham <b.n.barham@gmail.com>
Date:   Mon Oct 23 09:18:42 2023 -0700

    Merge pull request swiftlang#2309 from icanzilb/marin_todorov/command-help-typo-fix

    Fixes a typo in the cli abstract string

commit 46c39ad
Author: Marin Todorov <marin@underplot.com>
Date:   Sun Oct 22 11:16:36 2023 +0200

    fixes typo in a help string

commit 636556c
Author: Mateusz Bąk <bakmatthew@icloud.com>
Date:   Mon Sep 25 16:42:37 2023 +0200

    Add diagnostic testing utils for enhanced diagnostics testing

    Introduces `DiagnosticTestingUtils.swift`, a utility suite designed to aid in writing unit tests for `DiagnosticsFormatter` and `GroupedDiagnostics`. Highlights include:

    1. `LocationMarker` Typealias:
      - Enhances readability and precision in location identification within AST.

    2. `DiagnosticDescriptor` and `NoteDescriptor` Structs:
      - Offers a robust mechanism to construct and describe diagnostics and notes for testing.

    3. Simple Implementations for Protocols:
      - `SimpleNoteMessage` and `SimpleDiagnosticMessage` for streamlined testing.

    4. `assertAnnotated` Function:
      - Asserts that annotated source generated from diagnostics aligns with the expected output.

    This addition significantly bolsters the testing utilities, providing a comprehensive framework for ensuring accurate and effective diagnostics.

commit 6954167
Author: Mateusz Bąk <bakmatthew@icloud.com>
Date:   Mon Sep 25 16:39:16 2023 +0200

    Introduce diagnostic decorator

    This commit introduces three significant components:

    1. `DiagnosticDecorator` Protocol:
      - Defines a standard interface for decorating diagnostic output in source code.
      - Design to be used by entities like `DiagnosticsFormatter` and `GroupedDiagnostics`.

    2. `ANSIDiagnosticDecorator` Struct:
      - Implements the `DiagnosticDecorator` protocol.
      - Adds severity-based prefixes to diagnostic messages.
      - Supports ANSI colorization to enhance visibility and interpretation.

    3. `BasicDiagnosticDecorator` Struct:
      - Implements the `DiagnosticDecorator` protocol.
      - Adds severity-based prefixes to diagnostic messages.

    Also includes:
    - Unit tests for `ANSIDiagnosticDecorator` in `ANSIDiagnosticDecoratorTests` and `BasicDiagnosticDecorator` in `BasicDiagnosticDecoratorTests`.

    This feature enriches the diagnostic capabilities, offering customizable and visually informative feedback.

commit 953bab2
Author: Mateusz Bąk <bakmatthew@icloud.com>
Date:   Mon Sep 18 09:53:24 2023 +0200

    Rename DiagnosticsFormatterTests to ParserDiagnosticsFormatterIntegrationTests

commit 8fb1309
Author: Sophia Poirier <spoirier@apple.com>
Date:   Fri Oct 20 10:30:46 2023 -0700

    nonisolated(unsafe) to opt out of strict concurrency static checking for global variables

commit f8be751
Merge: 2223e4c e111f3a
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Fri Oct 20 10:05:52 2023 -0700

    Merge pull request swiftlang#2305 from Matejkob/new-extension-macro-example

    Add extension macro example

commit e111f3a
Author: Mateusz Bąk <bakmatthew@icloud.com>
Date:   Wed Oct 18 22:27:54 2023 +0200

    Add extension macro example

    This commit introduces a new macro, `DefaultFatalErrorImplementationMacro`, to provide default implementations for protocol methods. The macro automatically generates extension code blocks with the default implementations for any protocol it's attached to.

commit 2223e4c
Merge: 3fd8f49 45e92e8
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Thu Oct 19 17:07:39 2023 -0700

    Merge pull request swiftlang#2272 from divalue/syntax_tree_with_lookahead_struct

    Add IncrementalParseResult

commit 3fd8f49
Merge: 83e12ff 9a0f0ff
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Thu Oct 19 14:16:54 2023 -0700

    Merge pull request swiftlang#2278 from Matejkob/modifi-nodes-with-variable-setters

    Refactor syntax node manipulation to use variable setters

commit 9a0f0ff
Author: Mateusz Bąk <bakmatthew@icloud.com>
Date:   Thu Oct 12 09:11:56 2023 +0200

    Refactor syntax node manipulation to use variable setters

    This commit replaces the use of 'with' method for syntax node manipulation in SwiftSyntax examples with direct variable setters for better clarity and readability.

commit 83e12ff
Merge: f6868a7 d5400cb
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Wed Oct 18 15:18:32 2023 -0700

    Merge pull request swiftlang#2304 from ahoppen/ahoppen/trivia-comment

    Improve comment of leading and trailing trivia on `SyntaxProtocol`

commit d5400cb
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Wed Oct 18 13:19:30 2023 -0700

    Improve comment of leading and trailing trivia on `SyntaxProtocol`

commit f6868a7
Merge: 02a1330 b5c9937
Author: Kim de Vos <kimdevos12@hotmail.com>
Date:   Wed Oct 18 12:40:46 2023 +0200

    Merge pull request swiftlang#2286 from kimdv/kimdv/2273-bad-diagnostic-for-generic-parameter-list-on-enum-case

    Handle generic parameter on enum case

commit b5c9937
Author: Kim de Vos <kimdevos12@hotmail.com>
Date:   Sun Oct 15 20:18:58 2023 +0200

    Handle generic parameter on enum case

commit 02a1330
Merge: 106183a 33c4b08
Author: Kim de Vos <kimdevos12@hotmail.com>
Date:   Tue Oct 17 23:26:49 2023 +0200

    Merge pull request swiftlang#2226 from kimdv/kimdv/rewrite-fit-it-applier

    Rewrite FixItApplier to be string based

commit 106183a
Merge: e8659bb aa33736
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Tue Oct 17 12:41:23 2023 -0700

    Merge pull request swiftlang#2292 from ahoppen/ahoppen/case-iterable

    Remove `SyntaxKind` conformance to `CaseIterable`

commit 33c4b08
Author: Kim de Vos <kimdevos12@hotmail.com>
Date:   Tue Oct 17 08:32:46 2023 +0200

    Rewrite FixItApplier to be string based

commit e8659bb
Author: Rauhul Varma <rauhul@users.noreply.github.com>
Date:   Tue Oct 17 11:31:12 2023 -0700

    Fix missing space in LabeledExprSyntax init (swiftlang#2291)

    Updates LabeledExprSyntax convenience initializer to include a trailing
    space trivia after the colon if an argument label is specified. This
    ensures the rendered description is 'arg: value' instead of 'arg:value'.

commit aa33736
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Mon Oct 16 12:46:21 2023 -0700

    Remove `IntegerLiteralExprSyntax.Radix` conformance to `CaseIterable`

    There’s no good reason why you would want to iterate over all radix kinds.

commit a318593
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Tue Oct 17 09:41:05 2023 -0700

    Remove `SyntaxKind` conformance to `CaseIterable`

    There’s no good reason to iterate over all cases in `SyntaxKind` and if `SyntaxKind` conforms to `CaseIterable`, we can’t mark members of it as deprecated (https://github.com/apple/swift-syntax/pull/2237/files#r1359917461)

commit 1fa18e5
Merge: 975ac26 d8c8695
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Mon Oct 16 19:07:47 2023 -0700

    Merge pull request swiftlang#2296 from rintaro/cmake-nocache

    [CMake] Remove set(CACHE) line for SWIFT_MODULE_ABI_NAME_PREFIX

commit 975ac26
Merge: 8decbe4 e4e6a95
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Mon Oct 16 17:35:51 2023 -0700

    Merge pull request swiftlang#2268 from rintaro/macro-resolveerror-rdar115571427

    [Macros] Granular diagnostics when macro type is not found in a plugin

commit 8decbe4
Merge: 72565a4 947e6f3
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Mon Oct 16 17:34:09 2023 -0700

    Merge pull request swiftlang#2290 from ahoppen/ahoppen/interpolation-failure-message

    Update the interpolation failure message

commit d8c8695
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Mon Oct 16 13:50:05 2023 -0700

    [CMake] Remove set(CACHE) line for SWIFT_MODULE_ABI_NAME_PREFIX

    Due to https://cmake.org/cmake/help/latest/policy/CMP0126.html
    set(CACHE) overwrites the existing value if the cache has not been set
    to any value. Since we don't need any default value, just remove it.

commit 72565a4
Merge: ccab07f 7a3df8c
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Mon Oct 16 13:18:52 2023 -0700

    Merge pull request swiftlang#2285 from pointfreeco/add-missing-dependency

    Add missing dependency to SwiftSyntaxMacroExpansion.

commit 45e92e8
Author: Dmitrii Valuev <dima.vap2013@gmail.com>
Date:   Sun Oct 8 22:44:23 2023 +0300

    Add IncrementalParseResult type

    Added IncrementalParseResult type and changed parseIncrementally return type

    Fix spacing in 510 rn

commit 947e6f3
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Mon Oct 16 11:32:38 2023 -0700

    Update the interpolation failure message

    When a user is getting the interpolation `os_log` failure message but actually supports parsing invalid source code, offer them an alternative parses the source code without checking for errors.

commit e4e6a95
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Fri Oct 13 15:53:50 2023 -0700

    [CompilerPlugin] remove _resolveMacro

    That was only just a thunk for testing. Use @_spi(Testing) instead.

commit ccab07f
Merge: df6600d 093b895
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Mon Oct 16 09:03:30 2023 -0700

    Merge pull request swiftlang#2282 from rintaro/cmake-abi-name-rdar116951101

    [CMake] Add option to specify '-module-abi-name'

commit df6600d
Merge: e695b37 43c0388
Author: Kim de Vos <kimdevos12@hotmail.com>
Date:   Sun Oct 15 19:42:52 2023 +0200

    Merge pull request swiftlang#2264 from kimdv/kimdv/2261-rename-notemessagefixitid-to-noteid

    Rename `NoteMessage.fixItID` to `noteID`

commit 43c0388
Author: Kim de Vos <kimdevos12@hotmail.com>
Date:   Thu Oct 5 21:23:24 2023 +0200

    Rename `NoteMessage.fixItID` to `noteID`

commit 7a3df8c
Author: Brandon Williams <mbrandonw@hey.com>
Date:   Sat Oct 14 20:38:18 2023 -0400

    Add missing dependency to SwiftSyntaxMacroExpansion.

commit e695b37
Merge: 27db137 657f2e1
Author: Alex Hoppen <alex@alexhoppen.de>
Date:   Sat Oct 14 17:22:05 2023 -0700

    Merge pull request swiftlang#2063 from StevenWong12/move_swift_parser_cli

commit 27db137
Merge: 71afbc1 9a561e6
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Sat Oct 14 09:07:54 2023 -0700

    Merge pull request swiftlang#2283 from Matejkob/add-SwiftSyntax510

commit 9a561e6
Author: Mateusz Bąk <bakmatthew@icloud.com>
Date:   Sat Oct 14 10:43:43 2023 +0200

    Create `SwiftSyntax510` module for version indication

commit 093b895
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Sat Oct 14 06:17:40 2023 +0000

    [CMake] Add option to specify '-module-abi-name'

    Add 'SWIFT_MODULE_ABI_NAME_PREFIX' CMake variable. This can be used from
    compiler's CMake so its swift-syntax libraries can have unique names.
    That avoids symbol name conflicts when compiler libraries (e.g.
    sourcekitdInProc) is used from binaries linking with swift-syntax (e.g.
    via SwiftPM)

    swiftlang/swift#68812
    rdar://116951101

commit f413c51
Author: Rintaro Ishizaki <rishizaki@apple.com>
Date:   Wed Sep 20 14:53:11 2023 -0700

    [Macros] Granular diagnostics when macro type is not found in a plugin

    rdar://115571427

commit 71afbc1
Merge: fc58fc8 c5cb386
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Thu Oct 12 17:40:07 2023 -0700

    Merge pull request swiftlang#2277 from ahoppen/ahoppen/editor-extension-deployment-target

    Remove deployment target setting from editor extension

commit c5cb386
Author: Alex Hoppen <ahoppen@apple.com>
Date:   Thu Oct 12 09:13:48 2023 -0700

    Remove deployment target setting from editor extension

    This fixes a warning when building the Xcode project.

commit fc58fc8
Merge: 1f3618d acdbf3d
Author: Harlan Haskins <harlan@apple.com>
Date:   Wed Oct 11 22:42:19 2023 -0600

    Merge pull request swiftlang#2275 from apple/harlan/vintage-conformances

    Add support for '@retroactive' conformances in SwiftSyntaxParser

commit acdbf3d
Author: Harlan Haskins <harlan@apple.com>
Date:   Wed Oct 11 15:47:47 2023 -0600

    Update Types.swift

    Fixes a format error

commit 657f2e1
Author: Ziyang Huang <stevenhuang12@outlook.com>
Date:   Tue Oct 10 22:57:45 2023 +0800

    Run `swift-format` to format codes

commit cbd5764
Author: Harlan Haskins <harlan@apple.com>
Date:   Mon Oct 9 16:25:40 2023 -0600

    Add support for '@retroactive' conformances in SwiftSyntaxParser

commit 280fc3e
Author: Ziyang Huang <stevenhuang12@outlook.com>
Date:   Sun Oct 8 21:26:48 2023 +0800

    Rename `_InstructionCounter` in `SwiftParserCLI` to `InstructionCounter`

commit 264f676
Author: Ziyang Huang <stevenhuang12@outlook.com>
Date:   Tue Aug 22 22:10:28 2023 +0800

    Make CI build `SwiftParserCLI`

commit bdca1a4
Author: Ziyang Huang <stevenhuang12@outlook.com>
Date:   Sun Oct 8 21:23:04 2023 +0800

    Move `swift-parser-cli` to its own package
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants