mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
[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:
@@ -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);
|
||||
|
||||
|
||||
Reference in New Issue
Block a user