8000 Make `InferIsolatedConformances` and `StrictMemorySafety` migratable features by DougGregor · Pull Request #81703 · swiftlang/swift · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Make InferIsolatedConformances and StrictMemorySafety migratable features #81703

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

Merged
merged 7 commits into from
May 22, 2025

Conversation

DougGregor
Copy link
Member

Both InferIsolatedConformances and StrictMemorySafety have an automatable migration path. Make both into migratable features. This required some extensions to the "supported features" that the compiler provides for the migration tooling:

  • Each supported feature now provides the set of categories, which are the names of the diagnostic categories whose diagnostics should be considered part of that migration. We were assuming that the category name lined up with the feature name, which is not always the case (as with InferIsolatedConformances, whose diagnostic category is `IsolatedConformances).
  • Add optional features as a separate list, which should have a flag name associated with them. The only optional feature modeled this way right now is StrictMemorySafety.

When migrating, provide warnings that add 'nonisolated' to nonisolated
conformances that don't already have it and would end up being inferred
to be isolated under the upcoming feature.
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
The name of a migratable feature might differ from the names of the
diagnostic groups containing the diagnostics that are used to drive
migration for that feature. Provide the set of diagnostic categories
that are associated with each migratable feature as part of the
supported features list.
Optional language features don't have a specific "-enable-*" flag, because
they're rare and don't fit the same upcoming/experimental distinction. Add
a flag_name field to provide the flag name as well.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor DougGregor merged commit ca0e984 into swiftlang:main May 22, 2025
3 checks passed
@DougGregor DougGregor deleted the more-migratable-features branch May 22, 2025 15:48
Copy link
Contributor
@xedin xedin left a comment

Choose a reason for hiding this comment

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

LGTM!

// CHECK-NEXT: "upcoming": [
// CHECK: { "name": "{{.*}}"{{, "migratable": true}}, "enabled_in": "{{.*}}" }
// CHECK: { "name": "InferIsolatedConformances", "migratable": true, "categories": ["IsolatedConformances"], "enabled_in": "7" },
Copy link
Contributor

Choose a reason for hiding this comment

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

We really need to come up with a test that checks the structure here too...

Copy link
Member Author

Choose a reason for hiding this comment

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

If we have Foundation around, we could mock up some Codable structs/enums and make sure it deserializes

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
0