Skip to content

[move-only] Enable the move-only address transform and a small additional fix #62168

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

Conversation

gottesmm
Copy link
Contributor

This enables the full move only address transform. I was waiting for 525ba8c to land before landing this.

I also discovered a small problem around simple assignment when writing tests for this. (I thought that let _ = x and _ = x were codegened the same... but they are not).

…onsume the move only type.

This was an oversight since I thought that `let _ = x` and `_ = x` were
codegened in the same way.

rdar://102491017
…unctions, enable the main move only address transform.

The main constraint that we needed to fight here is that we are not allowed in
the move only address checker to expand exclusivity scopes since we run after
the main exclusivity passes. This means that to enable this transformation I
needed to add a new error diagnostic that is emitted if we are unable to convert
a loadCopyOrTake operation to a borrow like operation due to an exclusivity
scope that is too tight. Example:

```
%0 = begin_access [read] %addr
%1 = load [copy] %0
end_access %0
...
destroy_value %1
```

Luckily this does not actually happen for move only structs/move only enums
after 525ba8c which makes it so that we perform
a true borrow of those types when passing them to functions. If we pass a move
only class directly, we get the same behavior. Sadly if we pass a field from a
move only class, we still get a tight exclusivity scope and thus will emit an
error today. This is an issue that we can fight at a later time once we decide
to productize move only classes further. But at least structs/enums work
well. One can see this behavior by looking at all of the places that needed to
be updated as a result of this change.

rdar://102491093
@gottesmm
Copy link
Contributor Author

@swift-ci test

@glessard
Copy link
Contributor

@swift-ci Please Build Toolchain macOS Platform

@gottesmm gottesmm force-pushed the pr-361aa81d6d8a76244aebbad14d4342e76084e169 branch from e6dc231 to 89036b3 Compare November 18, 2022 01:17
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm
Copy link
Contributor Author

@swift-ci Please Build Toolchain macOS Platform

@gottesmm gottesmm merged commit 60aafef into swiftlang:main Nov 18, 2022
@gottesmm gottesmm deleted the pr-361aa81d6d8a76244aebbad14d4342e76084e169 branch November 18, 2022 05:57
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.

2 participants