-
Notifications
You must be signed in to change notification settings - Fork 412
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
Introduce Diagnostic Decorator and Testing Utilities #2238
Conversation
There was a problem hiding this 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? AFAICTANSIDiagnosticGenerator
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 theDiagnosticDecorator
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. |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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 ---
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Sources/SwiftDiagnostics/DiagnosticDecorators/DiagnosticDecorator.swift
Outdated
Show resolved
Hide resolved
af1e420
to
1fa1824
Compare
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:
The overarching vision for the 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 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
"""
You bring up a valid concern about making
Great point about immediate use. I've already integrated 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. |
There was a problem hiding this 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/DiagnosticDecorators/ANSIDiagnosticDecorator.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDiagnostics/DiagnosticDecorators/DiagnosticDecorator.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDiagnostics/DiagnosticDecorators/DiagnosticDecorator.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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
1fa1824
to
5896246
Compare
/// - 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. |
There was a problem hiding this comment.
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.
240a0fd
to
425ed9a
Compare
There was a problem hiding this 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 👍🏽
2ac8607
to
14b3f31
Compare
@swift-ci Please test |
CI failed with the following message:
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 |
Yeah, you'll need to add all the new files to cmake as well.
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. |
14b3f31
to
0668f63
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
@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.
Head branch was pushed to by a user without write access
0668f63
to
ade9844
Compare
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.
ade9844
to
636556c
Compare
Oops! I mistakenly committed a modified test and disabled the |
No problem. Let’s try again. @swift-ci Please test |
Is this the main problem |
Seems like an unrelated issue. Trying again. @swift-ci Please test macOS |
@swift-ci Please test Windows |
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
This PR is part of the efforts related to #2214.
Commit 1: Add
DiagnosticDecorator
Protocol,ANSIDiagnosticDecorator
andBacisDiagnosticDecorator
ImplementationsDiagnosticDecorator
, to standardize the decoration of diagnostic output.ANSIDiagnosticDecorator
, which provides ANSI colorization and severity-based prefixes for enhanced visibility.Commit 2: Introduce Diagnostic Testing Utilities
DiagnosticTestingUtils.swift
to facilitate more effective unit testing of diagnostics.