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.
- 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.
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Dynamic replacements are currently written in extensions as
extension ExtendedType {
@_dynamicReplacement(for: replacedFun())
func replacement() { }
}
The runtime implementation allows an implementation in the future where
dynamic replacements are gather in a scope and can be dynamically
enabled and disabled.
For example:
dynamic_extension_scope CollectionOfReplacements {
extension ExtentedType {
func replacedFun() {}
}
extension ExtentedType2 {
func replacedFun() {}
}
}
CollectionOfReplacements.enable()
CollectionOfReplacements.disable()
Otherwise, we can't represent a cross-reference to generic parameters
in a parent type /when used in an extension/.
https://bugs.swift.org/browse/SR-9084
Previously, the fast path for nested types only worked when the nested
type was defined in a Swift module or a Clang module without an
overlay; this is because it was originally designed to fix circularity
issues when merging partial modules for a single target. By having a
Swift overlay module pass through requests for nested types to the
underlying Clang module, we get the fast-path behavior in more cases.
(The one case where it /won't/ kick in is if the overlay has a nested
type that shadows a nested type from the Clang module, but that's
probably pretty rare!)
Add parsing, type checking, serialization, and deserialization support
for specifying multiple types as "designated" for operator lookup for
a given operator declaration.
The constraint solver still considers only the first type when
deciding the order to attempt the elements of a disjunction, so this
doesn't really change behavior yet.
We only need to have the identifier during type checking of operator
declarations, so we do not need to restore it from the
PrecedenceGroupDecl during deserialization. We can just use the
deserialized name from the PrecedenceGroupDecl directly if needed.
This does result in one change in behavior. When printing modules, we
previously didn't print 'DefaultPrecedence' for items that had no
precedence specified, but now we will as seen in the test update for
IDE/print_ast_tc_decls.swift.
Rather than limiting this to protocols, allow any nominal type.
Rename -enable-operator-designated-protocols to
-enable-operator-designated-types to reflect the change.
Augment the ASTPrinter to print the name and text of initializer expressions if
a property has an initializer and the type is @_fixed_layout and resides in a resilient module, and serialize the text for partial modules.
With this change, all .swiftinterface files in the project (except for SwiftLang) compile to swiftmodules on macOS.
rdar://43774580
rdar://43812188
Generic environments and archetypes can be expensive to deserialize
if they involve a generic signature not seen before.
Also, canonicalize the witness substitutions to eliminate type
aliases, and map them to interface types, which again are cheaper
to deserialize.
* Introduce stored inlinable function bodies
* Remove serialization changes
* [InterfaceGen] Print inlinable function bodies
* Clean up a little bit and add test
* Undo changes to InlinableText
* Add serialization and deserialization for inlinable body text
* Allow parser to parse accessor bodies in interfaces
* Fix some tests
* Fix remaining tests
* Add tests for usableFromInline decls
* Add comments
* Clean up function body printing throughout
* Add tests for subscripts
* Remove comment about subscript inlinable text
* Address some comments
* Handle lack of @objc on Linux
Not everything that goes into the "identifier table" is actually an
Identifier. If we don't need the string to be uniqued in the
ASTContext, don't bother calling getIdentifier.
May save some memory usage (and a string table lookup) for
deserialization.
The recovery logic was erronously kicking in, because it was comparing
the substituted underlying type with the declaration's underlying type.
For a generic typealias, these never equal, so instead, serialize the
unsubstituted type, and substitute it in deserialization.
* [AST] Remove stored TypeLoc from TypedPattern
TypedPattern was only using this TypeLoc as a means to a TypeRepr, which
caused it to store the pattern type twice (through the superclass and through
the TypeLoc itself.)
This also fixes a bug where deserializing a TypedPattern doesn't store
the type correctly and generally cleans up TypedPattern initialization.
Resolves rdar://44144435
* Address review comments
We were only setting overridden declarations on deserialized entities
when there was an overridden declaration, and not in the negative case.
This caused re-evaluation of overridden declarations after deserialization.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
Parsed declarations would create an untyped 'self' parameter;
synthesized, imported and deserialized declarations would get a
typed one.
In reality the type, if any, depends completely on the properties
of the function in question, so we can just lazily create the
'self' parameter when needed.
If the function already has a type, we give it a type right there;
otherwise, we check if a 'self' was already created when we
compute a function's type and set the type of 'self' then.
It's not clear whether we'll actually need this feature in the long
run, but we certainly need it now because non-@usableFromInline
members can (currently) satisfy public requirements when a
@usableFromInline internal type conforms to a public protocol. In
these cases, we'll treat the witnesses as present but opaque, and
clients will perform dynamic dispatch when using them even when
a generic function gets specialized.
With this, we're able to generate a textual interface for the standard
library, compile it back to a swiftmodule, and use it to build a Hello
World program!
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Instead of serializing the input type of a function type, which is a
TupleType or ParenType, serialize the individual parameters instead.
This means that we no longer need to serialize TupleTypes or
ParenTypes with custom flags, nor do we ever serialize standalone
InOutTypes, so all of that can be removed.
We can recover function, destructor, constructor, enum element
and subscript types from their parameter types and result type
(if present), by calling the AST's various computeType()
methods.
These methods don't do any more work than would be done if
we had deserialized the type and reconstructed it, so let's
just recompute it instead.
Note that we still serialize a ton of function types, due
to XREFs.
With my build configuration, this reduces the size of
Swift.swiftmodule by 237KiB (out of 20MiB).
SILFunctions no longer have a GenericParamList, so all of these
circularity and ordering problems are gone.
We *do* deserialize the generic parameters before creating decls
that have them though, so serialize generic parameters as if
their DeclContext was the DeclContext of the owner decl.
This is what we do when we parse generic parameters too; in
both cases, the constructor for the owner decl gives the
generic parameters the right DeclContext.
This allows us to dump it in the generated interface, though it's
still not syntax-highlighted. This is necessary for textual module
interfaces, but it's also just a longstanding request for Xcode's
"Generated Interface" / "Jump to Definition" feature.
rdar://problem/18675831
Way back in 6afe77d597 Chris removed the 'Parameter' type that tracked
extra information about parameters, collapsing it into ParamDecl and
making ParameterList "an overblown array of ParamDecl*'s". Do the same
thing for Serialization: push the few fields tracked in
PARAMETERLIST_ELT records down into PARAM_DECL, and then simplify the
PARAMETERLIST record to directly reference its parameters.
No functionality change.
Switch a number of callers of the Type-based lookupQualified() over to
the newer (and preferred) declaration-based lookupQualified(). These are
the easy ones; NFC.
