TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
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
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
Lifetime specifiers before parameter names were disallowed in Swift 3 (SE-0031).
`isolated`, `transferring` and `_const` got added after Swift 3 without a diagnostic to disallow them before parameter names.
Instead it is a bit on ParamDecl and SILParameterInfo. I preserve the consuming
behavior by making it so that the type checker changes the ParamSpecifier to
ImplicitlyCopyableConsuming if we have a default param specifier and
transferring is set. NOTE: The user can never write ImplicitlyCopyableConsuming.
NOTE: I had to expand the amount of flags that can be stored in ParamDecl so I
stole bits from TypeRepr and added some logic for packing option bits into
TyRepr and DefaultValue.
rdar://121324715
The reason why I am doing this is that I am going to be changing transferring to
not be a true ParamSpecifier. Instead, it is going to be a bit on Param that
changes the default ParamSpecifier used. That being said, I cannot use consuming
for this purpose since consuming today implies no implicit copy semantics, which
we do not want unless the user specifically asks for it by writing consuming.
The old TypeAttributes reprsentation wasn't too bad for a small number of
simple attributes. Unfortunately, the number of attributes has grown over
the years by quite a bit, which makes TypeAttributes fairly bulky even at
just a single SourceLoc per attribute. The bigger problem is that we want
to carry more information than that on some of these attributes, which is
all super ad hoc and awkward. And given that we want to do some things
for each attribute we see, like diagnosing unapplied attributes, the linear
data structure does require a fair amount of extra work.
I switched around the checking logic quite a bit in order to try to fit in
with the new representation better. The most significant change here is the
change to how we handle implicit noescape, where now we're passing the
escaping attribute's presence down in the context instead of resetting the
context anytime we see any attributes at all. This should be cleaner overall.
The source range changes around some of the @escaping checking is really a
sort of bugfix --- the existing code was really jumping from the @ sign
all the way past the autoclosure keyword in a way that I'm not sure always
works and is definitely a little unintentional-feeling.
I tried to make the parser logic more consistent around recognizing these
parameter specifiers; it seems better now, at least.
Follow the feature flag convention for capitalization and be
consistent with the related NoncopyableGenerics feature.
This is a new feature that no wild Swift code has used it yet:
commit e99ce1cc5d
Author: Kavon Farvardin <kfarvardin@apple.com>
Date: Tue Dec 5 23:25:09 2023
[NCGenerics] add `~Escapable`
Basic implementation of `~Escapable` in the type system.
We accepted unnamed closure parameters if the type was an array literal, dictionary literal, tuple or function (because the `[` or `(` starting the type was sufficient to disambiguate the type from the parameter’s name). This was never an accepted syntax and we should disallow it.
There are sometimes parsing stuations where we don't want to
emit a parsing error, because of feature guarding. For
example, if a Feature involves new syntax for a type, we
must be able to parse both the true and false sides of an
ifdef guarding that new syntax based on a Feature flag.
Parse typed throw specifiers as `throws(X)` in every place where there
are effects specified, and record the resulting thrown error type in
the AST except the type system. This includes:
* `FunctionTypeRepr`, for the parsed representation of types
* `AbstractFunctionDecl`, for various function-like declarations
* `ClosureExpr`, for closures
* `ArrowExpr`, for parsing of types within expression context
This also introduces some serialization logic for the thrown error
type of function-like declarations, along with an API to extract the
thrown interface type from one of those declarations, although right
now it will either be `Error` or empty.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
SE-0382 allows macro parameters to have default arguments. Enable these
default arguments, with the normal type checking rules. One
significant quirk to this implementation is that the actual default
argument values don't make it to the macro implementation. This is a
previously-unconsidered design problem we'll need to address.
Tracked by rdar://104043987.
Cursor info only cares about the `doneParsing` callback and not about all the `complete` functions that are now defined in `CodeCompletionCallbacks`. To make the design clearer, split `IDEInspectionCallbacks`.
rdar://105120332
This replaces `synthesizeTildeEqualsOperatorApplication`,
and synthesizes the match expression and var
on-demand.
Additionally, it pushes the lookup logic into
pre-checking.
In my earlier commit that attempted to do this I wasn't aggressive enough. In
this commit, I was more aggressive in putting it behind a flag and as a result
we reject all of the patterns in the tests I added into tree.
And adjust contextual parameter modifier parsing in general to be more
properly contextual, so we don't have to reserve `__shared` or `__owned`,
or their successor spellings, as argument labels anymore.
And do a first pass of auditing existing uses of the parameter specifiers to
make sure that we look at the ValueOwnership mapping in most cases instead of
individual modifiers.
This lets us consolidate code paths that mostly run in parallel over the
existing InOutTypeRepr/SharedTypeRepr/OwnedTypeRepr family of types. This
patch by itself is NFC but makes it easier to introduce new spellings,
particularly the newly-official `borrowing` and `consuming` modifiers
that were approved in SE-0377.
Per the current proposal, these are to be specified
explicitly, as they form an important part of the API.
Bonus: This commit includes a fix to make
`CompileTimeConstTypeRepr` a proper `isa<>` subtype of
`SpecifierTypeRepr`, since we forgot to add it to
that type's `classof` function.
resolves rdar://105480354
