[sending] Begin parsing 'sending' while still accepting 'transferring'.

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
This commit is contained in:
Michael Gottesman
2024-05-16 14:28:40 -07:00
parent 71e95b9527
commit b780ff6696
58 changed files with 946 additions and 236 deletions

View File

@@ -1064,6 +1064,17 @@ static bool ParseLangArgs(LangOptions &Opts, ArgList &Args,
Opts.enableFeature(Feature::RegionBasedIsolation);
}
// Enable SendingArgsAndResults whenever TransferringArgsAndResults is
// enabled.
//
// The reason that we are doing this is we want to phase out transferring in
// favor of sending and this ensures that if we output 'sending' instead of
// 'transferring' (for instance when emitting suppressed APIs), we know that
// the compiler will be able to handle sending as well.
if (Opts.hasFeature(Feature::TransferringArgsAndResults)) {
Opts.enableFeature(Feature::SendingArgsAndResults);
}
Opts.WarnImplicitOverrides =
Args.hasArg(OPT_warn_implicit_overrides);