Skip to content

[move-keyword] Change from using a move function -> move keyword. #60404

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

@gottesmm gottesmm commented Aug 5, 2022

This PR does 2 things:

  1. It changes the implementation of the move function to instead be driven by a move keyword. I updated all of the tests to use this and everything passes.
  2. I took advantage of this change in representation to make it so that SILGen is guaranteed to not copy the move's operand into a temporary before the move is evaluated.

@gottesmm gottesmm requested a review from jckarter August 5, 2022 02:45
@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 5, 2022

@swift-ci test

@@ -357,6 +367,13 @@ static void diagSyntacticUseRestrictions(const Expr *E, const DeclContext *DC,
}
}

void checkMoveExpr(MoveExpr *moveExpr) {
if (!isa<DeclRefExpr>(moveExpr->getSubExpr())) {
Ctx.Diags.diagnose(moveExpr->getLoc(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jckarter do you think I need to check for more things here? When I talked with @DougGregor he mentioned to check that this check also catches field accesses (which it does)... but I figured I would ask out of an abundance of caution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that we need an ironclad AST-level diagnostic here, since we will still need a diagnostic in SIL anyway to detect lvalues that can't be statically moved. So I think this is fine to reject obviously unsupportable cases.

@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 5, 2022

Another additional nice thing is that b/c the SILGen emission always works pretty much how I want it, I don't need to rely upon the move function canonicalization pass. I am going to rip that out in a subsequent PR.

@gottesmm gottesmm force-pushed the pr-4dfd8089258ab2b78ff84b6ac4f4c425b321653d branch from 085642c to ae00539 Compare August 5, 2022 03:24
@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 5, 2022

Test failed b/c in the mean time someone added another syntax node so there was a node numbering collision. I just rebased/added one to MoveExpr's serialization number.

@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 5, 2022

@swift-ci test

@gottesmm gottesmm force-pushed the pr-4dfd8089258ab2b78ff84b6ac4f4c425b321653d branch from ae00539 to 2874760 Compare August 5, 2022 05:46
@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 5, 2022

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 6, 2022

@gottesmm gottesmm force-pushed the pr-4dfd8089258ab2b78ff84b6ac4f4c425b321653d branch from 2874760 to c670516 Compare August 6, 2022 22:42
@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 6, 2022

I did this by requiring this in the typechecker. This will ensure that when we
emit a move, we are guaranteed to have a value decl ref that we can evaluate. It also ensures that we can't _move fields.

auto
…emission.

I also updated the move function tests to show that this is working. As a nice
bonus, I was able to enable all of the tests also in a non-optimized stdlib.
@gottesmm gottesmm force-pushed the pr-4dfd8089258ab2b78ff84b6ac4f4c425b321653d branch from c670516 to e9d8f36 Compare August 8, 2022 19:54
@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 8, 2022

Swift syntax PR: swiftlang/swift-syntax#563

@gottesmm
Copy link
Contributor Author

gottesmm commented Aug 8, 2022

@gottesmm gottesmm merged commit 8e235d7 into swiftlang:main Aug 8, 2022
@gottesmm gottesmm deleted the pr-4dfd8089258ab2b78ff84b6ac4f4c425b321653d branch August 8, 2022 23:45
@philipturner
Copy link
Contributor

@gottesmm This is breaking a library I actively maintain. There is a function called _move in Swift for TensorFlow, which now breaks because of the _move keyword you added. I made a workaround to escape it with backticks, but a lot of forks and branches will break because they don't incorporate the workaround.

Reported in: #60492

Final reproducer: #60492 (comment)

If this is desired behavior, could we incorporate my reproducer into the Swift test suite, so that it's explicit that we want such code to fail?

@gottesmm
Copy link
Contributor Author

@philipturner I actually put it behind an option in a subsequent so it shouldn't break you. The final name is still under discussion, but once that is finalized, I am happy to add a test.

@philipturner
Copy link
Contributor

I already escaped _move with backticks in the main branch of S4TF, so my work won't be broken by whatever happens in the future. But thanks for letting me know about about the compiler option!

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.

3 participants