This does not eliminate the entrypoints on SILBuilder yet. I want to do this in
two parts so that it is functionally easier to disentangle changing the APIs
above SILBuilder and changing the underlying instruction itself.
rdar://33440767
* [InterfaceGen] Remove #ifs from default args
This patch removes all #if configs form the bodies of default arguments,
which can contain multiline closures, while preserving the bodies of the
clauses that are active.
This code is generalized and should "just work" for inlinable function
bodies, which will come in a later patch.
* Address review comments
* Fix and test CharSourceRange.overlaps
* Fix CharSourceRange::print to respect half-open ranges
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!
This isn't just an optimization; we weren't recording that the
attribute was invalid, and so it was getting /treated as valid/ when
the module was imported into a client later.
This would have caught the issue fixed by the previous commit.
- 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.
Previously SILModule contained two different pathways for the deserializer to
send notifications that it had created functions:
1. A list of function pointers that were called when a function's body was
deserialized. This was added recently so that access enforcement elimination is
run on newly deserialized SIL code if we have already eliminated access
enforcement from the module.
2. SILModule::SerializationCallback. This is an implementation of the full
callback interface and is used by the SILModule to update linkage and other
sorts of book keeping.
To fix the pass manager notification infrastructure, I need to be able to send
notifications to a SILPassManager when deserializing. I also need to be able to
eliminate these callbacks when a SILPassManager is destroyed. These requirements
are incompatible with the current two implementations since: (2) is an
implementation detail of SILModule and (1) only notifies on function bodies
being deserialized instead of the creation of new declarations (what the caller
analysis wants).
Rather than adding a third group of callbacks, this commit refactors the
infrastructure in such a way that all of these use cases can use one
implementation. This is done by:
1. Lifting the interface of SerializedSILLoader::Callback into a base
notification protocol for deserialization called
DeserializationNotificationHandlerBase and its base no-op implementation into an
implementation of the aforementioned protocol:
DeserializationNotificationHandler.
2. Changing SILModule::SerializationCallback to implement
DeserializationNotificationHandler.
3. Creating a class called FunctionBodyDeserializationNotificationHandler that
takes in a function pointer and uses that to just override the
didDeserializeFunctionBody. This eliminates the need for the specific function
body deserialization list.
4. Replacing the state associated with the two other pathways with a single
DeserializationNotificationHandlerSet class that contains a set of
DeserializationNotificationHandler and chains notifications to them. This set
implements DeserializationNotificationHandlerBase so we know that its
implementation will always be in sync with DeserializationNotificationHandler.
rdar://42301529
ConvertFunction and reabstraction thunks need this attribute. Otherwise,
there is no way to identify that withoutActuallyEscaping was used
to explicitly perform a conversion.
The destination of a [without_actually_escaping] conversion always has
an escaping function type. The source may have either an escaping or
@noescape function type. The conversion itself may be a nop, and there
is nothing distinctive about it. The thing that is special about these
conversions is that the source function type may have unboxed
captures. i.e. they have @inout_aliasable parameters. Exclusivity
requires that the compiler enforce a SIL data flow invariant that
nonescaping closures with unboxed captures can never be stored or
passed as an @escaping function argument. Adding this attribute allows
the compiler to enforce the invariant in general with an escape hatch
for withoutActuallyEscaping.
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).
Actually, the biggest win here seems to be not recording parameters,
which were taking up a ridiculous amount of space in the generated
swiftdoc. This change takes Swift.swiftdoc from 5MB to 3.5MB.
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.
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
Before:
module file's minimum deployment target is iOS 12.0:
/path/to/FooKit.swiftmodule
After:
compiling for iOS 11.0, but module 'FooKit' has a minimum deployment
target of iOS 12.0: /path/to/FooKit.swiftmodule
Also tweak the "incompatible target" error to include the module name.
rdar://problem/35546499
This was removed upstream in https://reviews.llvm.org/D47789 since the only
place this flag was used was in the windows implementation where the behavior
triggered by this could be hidden in the implementation instead of being an
argument. As such, this code doesn't compile on master-next.
Since this has an acceptable default argument given the current stable, we can
just fix this on master and everything will work.
rdar://42862352
This replaces the use of a Clang utility function that was
inexplicably a non-static member function of CompilerInstance. It
would be nice to sink this all the way to LLVM and share the
implementation across both projects, but the Clang implementation does
a handful of things we don't need, and it's hard to justify including
them in an LLVM-level interface. (I stared at
llvm/Support/FileSystem.h for a long time before giving up.)
Anyway, Serialization and FrontendTool both get their atomic writes
now without depending on Clang, and without duplicating the
scaffolding around the Clang API. We should probably adopt this for
all our output files.
No functionality change.
This allowed me to fold all of the weird direct calls to createFunction into a
singular SILSerializationFunctionBuilder::createDeclaration. This is the only
API that is needed by the SILParser so only providing that gives us a
significantly cleaner API.
rdar://42301529
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
We previously shied away from this in order to not /accidentally/
depend on it, but it becomes interesting again with textual
interfaces, which can certainly be read by humans. The cross-file
order is the order of input files, which is at least controllable by
users.
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.
This commit does not modify those APIs or their usage. It just:
1. Moves the APIs onto SILFunctionBuilder and makes SILFunctionBuilder a friend
of SILModule.
2. Hides the APIs on SILModule so all users need to use SILFunctionBuilder to
create/destroy functions.
I am doing this in order to allow for adding/removing function notifications to
be enforced via the type system in the SILOptimizer. In the process of finishing
off CallerAnalysis for FSO, I discovered that we were not doing this everywhere
we need to. After considering various other options such as:
1. Verifying after all passes that the notifications were sent correctly and
asserting. Turned out to be expensive.
2. Putting a callback in SILModule. This would add an unnecessary virtual call.
I realized that by using a builder we can:
1. Enforce that users of SILFunctionBuilder can only construct composed function
builders by making the composed function builder's friends of
SILFunctionBuilder (notice I did not use the word subclass, I am talking
about a pure composition).
2. Refactor a huge amount of code in SILOpt/SILGen that involve function
creation onto a SILGenFunctionBuilder/SILOptFunctionBuilder struct. Many of
the SILFunction creation code in question are straight up copies of each
other with small variations. A builder would be a great way to simplify that
code.
3. Reduce the size of SILModule.cpp by 25% from ~30k -> ~23k making the whole
file easier to read.
NOTE: In this commit, I do not hide the constructor of SILFunctionBuilder since
I have not created the derived builder structs yet. Once I have created those in
a subsequent commit, I will hide that constructor.
rdar://42301529
print and parse as a stable hexadecimal form that isn't interpreted as UTF8.
One use case is in representing serialized protobuf strings (as in the
tensorflow branch: f7ed452eba/lib/SILOptimizer/Mandatory/TFPartition.cpp (L3875)).
The original work was done by @lattner and merged into the tensorflow
branch. This PR is to upstream those changes.
