-
Notifications
You must be signed in to change notification settings - Fork 78
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
Adopt Swift 6.0 Tools Version #615
base: main
Are you sure you want to change the base?
Conversation
I am happy to merge this, I do not have any objections to it. You said it was experimental, do you have any concerns about it? I have the patches updated and merged locally. |
I don't think there are any concerns if you're happy for people to need a Swift 6.0 toolchain. |
One thought - I wonder if the version number of swift-syntax could/should be bumped up? |
566e026
to
aff34ce
Compare
I tried this and it seemed to go ok, with only minimal changes required. I'm not sure if there are any other implications. I rebased the branch as a result, but you said you already have an updated/merged patch locally so if it's easier to go with that, I can always re-submit the extra bit as a different PR -- just let me know. |
This is an experiment.This changes swift-tools-version to 6.0, but then opts out all of the non-plugin targets from the Swift 6.0 language mode (for now).
There is no way to opt out for plugins, so they are updated (the updates are fairly trivial).
Partly I did this to see whether forcing the tools version to 6.0 helped with any of the Windows build problems.
It does also have the advantage that we can migrate targets to Swift 6.0 one at a time, when the time comes.
Obviously this change would force a dependency on the Swift 6.x toolchain. That may be a good thing, if it reduces the need to cope with legacy compiler weirdness (eg windows compiler features lagging behind).