Skip to content

Conversation

@DougGregor
Copy link
Member

Fix a number of issues related to strict memory safety's handling of safe types nested within unsafe ones, including:

  • Don't propagate @unsafe from a type to its nested types automatically
  • A reference to a safe type nested within an unsafe type is safe; don't diagnose it as unsafe
  • Typealiases cannot be meaningfully unsafe if their underlying type isn't
  • Lots of standard library updates that remove extraneous unsafe uses

This clears up a number of false positives with strict memory safety that I've encountered in practice, tracked by rdar://149628760

Typealiases involving unsafe types that resolve to safe types
should not be diagnosed.
…rd libraries

Now that we aren't propagating "unsafe" to nested types, remove
unnecessary "unsafe" keywords from the standard library.
…eir enclosing type

When determining whether a nested type is safe, don't consider whether
its enclosing type is safe. They're independent.
… types

Use this to mark a few internal types @safe now that it works properly.
…as implicitly 'unsafe'

This eliminates stray warnings.
@DougGregor DougGregor requested review from a team, hborla, ktoso, slavapestov and xedin as code owners April 20, 2025 05:02
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor DougGregor enabled auto-merge April 20, 2025 05:03
@DougGregor DougGregor merged commit 54e4400 into swiftlang:main Apr 20, 2025
3 checks passed
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