[SE-0458] Enable unsafe expressions / attributes / for..in effects by default #79645
Merged
Merged
Conversation
Allow a conformance to be "isolated", meaning that it stays in the same isolation domain as the conforming type. Only allow this for global-actor-isolated types. When a conformance is isolated, a nonisolated requirement can be witnessed by a declaration with the same global actor isolation as the enclosing type.
When a protocol conformance somehow depends on an isolated conformance, it must itself be isolated to the same global actor as the conformance on which it depends.
… default With the acceptance of SE-0458, allow the use of unsafe expressions, the @safe and @unsafe attributes, and the `unsafe` effect on the for..in loop in all Swift code. Introduce the `-strict-memory-safety` flag detailed in the proposal to enable strict memory safety checking. This enables a new class of feature, an optional feature (that is *not* upcoming or experimental), and which can be detected via `hasFeature(StrictMemorySafety)`.
Port over the disambiguation code we already had in the new Swift parser to the existing C++ parser for the "unsafe" expression and for..in effect.
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
The first few commits here are from #79624, which I thought would have merged by now 😢 |
2 tasks
stmontgomery
added a commit
to swiftlang/swift-testing
that referenced
this pull request
Apr 19, 2025
…ting 6.1 development snapshot toolchains (#1084) This fixes a build failure when attempting to build the `main` branch using a 6.1 development snapshot toolchain. This failure was introduced by #1069, which added usage of the new `@unsafe` attribute, and the failure was revealed when we set up the 6.1 CI jobs in #1083. Here are some relevant related Swift PRs which give context around these changes: - swiftlang/swift#75413 - swiftlang/swift#79645 See the code comment for more details. ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the acceptance of SE-0458, allow the use of unsafe expressions, the
@safeand@unsafeattributes, and theunsafeeffect on the for..in loop in all Swift code.Introduce the
-strict-memory-safetyflag detailed in the proposal to enable strict memory safety checking. This enables a new class of feature, an optional feature (that is not upcoming or experimental), and which can be detected viahasFeature(StrictMemorySafety).To do this, bring over the remaining disambiguation logic for the
unsafeexpression andfor..ineffect from the new Swift parser to the old Swift parser.