Skip to content

[SE-0458] Enable unsafe expressions / attributes / for..in effects by default #79645

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 5 commits into from
Feb 27, 2025

Conversation

DougGregor
Copy link
Member

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).

To do this, bring over the remaining disambiguation logic for the unsafe expression and for..in effect from the new Swift parser to the old Swift parser.

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.
@DougGregor
Copy link
Member Author

swiftlang/swift-syntax#2978

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

DougGregor commented Feb 26, 2025

The first few commits here are from #79624, which I thought would have merged by now 😢

@DougGregor DougGregor merged commit db0d658 into swiftlang:main Feb 27, 2025
3 checks passed
@DougGregor DougGregor deleted the enable-se-0458-by-default branch February 27, 2025 02:52
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.
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.

1 participant