[sending] Add support for 'sending' #73696
Merged
Conversation
This file contains 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
…' instead of 'transferring'. We still only parse transferring... but this sets us up for adding the new 'sending' syntax by first validating that this internal change does not mess up the current transferring impl since we want both to keep working for now. rdar://128216574
…ransferring. Just trying to slice off a larger change where I change these tests to actually use 'sending'. This is nice to do now since it is algebraic to do. rdar://128216574
gottesmm
requested review from
ahoppen,
bnbarham,
CodaFi,
DougGregor,
hamishknight,
rintaro,
ktoso,
mikeash,
al45tair,
a team,
AnthonyLatsis,
hborla,
slavapestov,
xedin,
zoecarver,
hyp,
egorzhdan and
tshortli
as code owners
|
@swift-ci smoke test |
hborla
reviewed
May 17, 2024
A few things: 1. Internally except for in the parser and the clang importer, we only represent 'sending'. This means that it will be easy to remove 'transferring' once enough time has passed. 2. I included a warning that suggested to the user to change 'transferring' -> 'sending'. 3. I duplicated the parsing diagnostics for 'sending' so both will still get different sets of diagnostics for parsing issues... but anywhere below parsing, I have just changed 'transferring' to 'sending' since transferring isn't represented at those lower levels. 4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So we import "transferring" as "sending". This means that even if one marks a function with "transferring", the compiler will guard it behind a SendingArgsAndResults -D flag and in the imported header print out sending. rdar://128216574
I am doing this after the main transformation to ease commit by commit understanding of the change. rdar://128216574
gottesmm
force-pushed
the
rdar128216574
branch
3 times, most recently
from
5a1e07b
to
3d456ed
Compare
ktoso
approved these changes
May 17, 2024
|
I think this also needs a corresponding parser change in swift-syntax. |
|
@swift-ci smoke test |
…e SE-0430 an upcoming feature. I also added support for expressing suppressable upcoming features. rdar://128216574
|
@swift-ci smoke test |
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.
This PR adds support to the compiler for 'sending'. It does not completely remove 'transferring' (since it may already be used). Instead what it does is:
Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
I included a warning that suggested to the user to change 'transferring' ->
'sending'.
I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574