SILGen: Emit move-only bases for lvalues in a borrow scope. #65302
Conversation
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
Normally, if we project from a mutable class ivar or global variable, we'll load a copy in a tight access scope and then project from the copy, in order to minimize the potential for exclusivity violations while working with classes and copyable values. However, this is undesirable when a value is move-only, since copying is not allowed; borrowing the value in place is the expected and only possible behavior. rdar://105794506
|
@swift-ci Please test |
kavon
reviewed
Apr 20, 2023
Comment on lines
+2814
to
+2817
| // If the base is a load of a noncopyable type (or, eventually, when we have | ||
| // a `borrow x` operator, the operator is used on the base here), we want to | ||
| // apply the lvalue within a formal access to the original value instead of | ||
| // an actual loaded copy. |
There was a problem hiding this comment.
So we do have the expression form _borrow x behind -enable-experimental-move-only, so it's worth checking if this also works for that too. This:
struct X: ~Copyable {
var something: Int { return 1 }
}
func f() -> Int {
var x = X()
return (_borrow x).something
}
gives an AST like this:
(member_ref_expr ...
(paren_expr ...
(load_expr implicit type='X' ...
(borrow_expr type='@lvalue X' ...
(declref_expr type='@lvalue X' ... )))))
It doesn't appear that SILGenLValue has a visitor for a BorrowExpr yet, so this might crash now (haven' tried your branch yet).
Comment on lines
+15
to
+17
| // error: 'self.val' has consuming use that cannot | ||
| // be eliminated due to a tight exclusivity scope | ||
| return val.empty // note: consuming use here |
There was a problem hiding this comment.
maybe we can remove these comments now that it's working
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Normally, if we project from a mutable class ivar or global variable, we'll load a copy in a tight access scope and then project from the copy, in order to minimize the potential for exclusivity violations while working with classes and copyable values. However, this is undesirable when a value is move-only, since copying is not allowed; borrowing the value in place is the expected and only possible behavior. rdar://105794506