-
Notifications
You must be signed in to change notification settings - Fork 439
Fix a minor threading issue and TODO by switching to structured concurrency #2245
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
Conversation
@swift-ci please test |
Thanks @benpious! Out of interest, did you see any increase in generation time with this change? |
I didn't notice any when I originally wrote it, and in my tests there doesn't seem to be any difference. I ran |
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.
Very nice. 🤩 I only have one minor comment to make the code slightly more readable, otherwise looks very good to me.
CodeGeneration/Sources/generate-swift-syntax/GenerateSwiftSyntax.swift
Outdated
Show resolved
Hide resolved
fileprivate func generateFile( | ||
contents: @autoclosure () -> String, | ||
destination: URL, | ||
verbose: Bool | ||
) throws { |
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’m happy with making this a top-level function but just FYI, you could keep this a member of GenerateSwiftSyntax
if you mark the function as nonisolated
.
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 doesn't actually use any members, so IMO a top level fileprivate function makes sense anyway.
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 turns out you don't have to even mark it as nonisolated
in the current setup of run
, it still works.
I originally made this change because when I tried to mark run
as async without changing the conformance to the async version of ParseableCommand
, the compiler error kind of implied this was the problem. That was not the case.
So I don't have a strong opinion on this, but I'm partial to the top level free function.
Thanks for checking! |
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 the updates! LGTM, could you squash your commits and add a commit message, see https://github.com/apple/swift-syntax/blob/main/CONTRIBUTING.md#authoring-commits? I'll start testing after that so we don't have to run it twice.
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.
Thank you for the PR. Looks very good to me and great to see Swift Concurrency making its way into swift-syntax 👍🏽
a6e3cb3
to
da9efb0
Compare
…threads by switching to Structured Concurrency from GCD, allowing the compiler to prevent future bugs of this nature from being written
da9efb0
to
8a9ecd5
Compare
Done! |
@swift-ci please test |
FWIW it's generally good practice to have a max 72 length title (to avoid truncation with the rest added to description). No need to fix for this commit, I've started testing. Thanks again! |
@swift-ci Please test macOS |
In #2233, it was suggested that a better long term direction was to adopt Structured Concurrency. This PR does exactly that.
The issue this pr is fixing is that the
errors
var had no synchronization and could cause crashes if it was written to.