Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
* Moves the IsStatic flag from VarDecl to AbstractStorageDecl.
* Adds a StaticSubscriptKind to SubscriptDecl.
* Updates serialization for these changes.
* Updates SubscriptDecl constructor call sites for these changes.
We already detected when a typealias /changed/ incompatibly; being
unable to deserialize it at all is just a very dramatic version of
that, right?
https://bugs.swift.org/browse/SR-9811
Introduce stored property default argument kind
Fix indent
Assign nil to optionals with no initializers
Don't emit generator for stored property default arg
Fix problem with rebase
Indentation
Serialize stored property default arg text
Fix some tests
Add missing constructor in test
Print stored property's initializer expression
cleanups
preserve switch
complete_constructor
formatting
fix conflict
It still has side effects, and it's still a lambda rather than a
helper function because it's not used anywhere else, but `[&]`
captures in helper lambdas make me nervous (as opposed to callback
lambdas).
Decls need to do this to avoid re-entrancy issues, but it turns out
types are simpler. I left a dummy "result" variable in the minimize
churn, since I'm going to move all the cases into their own functions
anyway.
...as a proof of concept. The next commit will move them /all/ out of
line.
(The intent here is to produce better backtraces when not recovering
from errors.)
A refinement of Doug's e3207f753c from a year ago to account for
trying to reference an import-as-member error enum /through/ an
overlay when it's in a Clang module using 'export_as'. The problem is
that importing error enums synthesizes a corresponding struct, and
that struct doesn't have a Clang node and so when it isn't found in
the right module the compiler didn't know to allow it anyway.
I know, right?
(Looking at the source change might be simpler than trying to read
the above paragraph.)
I'm still not 100% sure on how this occurred in the original
(Apple-internal) projects hitting this, but I think it's just that we
handle all import-as-member types at once, and the clients were using
something else from a type that contained the error enum, and then
that resulted in the error struct's conformances getting written into
a serialized swiftmodule.
rdar://problem/47152185
GenericParamList::OuterParameters would mirror the nesting structure
of generic DeclContexts. This resulted in redundant code and caused
unnecessary complications for extensions and protocols, whose
GenericParamLists are constructed after parse time.
Instead, lets only use OuterParameters to link together the multiple
parameter lists of a single extension, or parameter lists in SIL
functions.
This code used GenericParamList::getOuterParameters() and
DeclContext::getGenericParamsOfContext(). The meaning of the
former is about to change, and the latter is going away.
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
- The GenericSignatureBuilder assumed it didn't have to look in
protocol extensions to resolve member types.
- Serialization was incorrectly filtering out such typealiases when
trying to resolve a cross-module reference to one.
rdar://problem/46103190
This is actually two separate problems:
- 'override' wasn't getting added to initializers in deserialization
- 'override' was getting added when inheriting a 'required' initializer,
even though it's normally an error to write that
Needed for parseable interfaces.
Now that we don't store requirements in the GenericParamList, there's
no reason to use trailing records to list out the
GenericTypeParamDecls.
No functionality change.
Re-applied after fixing a bug in Serialization where the DeclContext
wasn't being set correctly for extensions with nested parameters. I
was unable to come up with a reduced test case, but the CoreStore
project in the source compatibility suite was failing without the
Serialization change, and now it isn't.
