* Factor out ASTContext plugin loading to newly introduced 'PluginLoader'
* Insert 'DependencyTracker' to 'PluginLoader'
* Add dependencies right before loading the plugins
rdar://104938481
Allowed SILFunctionType instances for pseudogeneric coroutines without
signatures to be created. Such instances are created by
SILTypeSubstituter::substSILFunctionType when SILGen'ing a conformance
of a pseudogeneric type to a protocol featuring a coroutine requirement.
rdar://81421394
For a `@Testable` import in program source, if a Swift interface dependency is discovered, and has an adjacent binary `.swiftmodule`, open up the module, and pull in its optional dependencies. If an optional dependency cannot be resolved on the filesystem, fail silently without raising a diagnostic.
The only state `getSwiftName` uses is its argument, and can be made a free function. Of
note the inverse operation, `getKnownFoundationEntity`, is also a free function. This
removes the requirement that callers have an `ASTContext` instance.
(cherry-picked from commit fb524c0b86)
`LoadedLibraryPlugin` is currently just a wrapper of `void` pointer from
`dlopen`. This will be convenient for abstracting platform specific
dynamic linrary handling.
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
The macro name resolution in the source lookup cache was only looking at
macros in the current module, meaning that any names introduced by peer
or declaration macros declared in one module but used in another would
not be found by name lookup.
Switch the source lookup cache over to using the same
`forEachPotentialResolvedMacro` API that is used by lookup within
types, so we have consistent name-lookup-level macro resolution in both
places.
... except that would be horribly cyclic, of course, so introduce name
lookup flags to ignore top-level declarations introduced by macro
expansions. This is semantically correct because macro expansions are
not allowed to introduce new macros anyway, because that would have
been a terrible idea.
Fixes rdar://107321469. Peer and declaration macros at module scope
should work a whole lot better now.
Substitution of a pack expansion type may now produce a pack type.
We immediately expand that pack when transforming a tuple, a function
parameter, or a pack.
I had to duplicate the component-wise transformation logic in the
simplifyType transform, which I'm not pleased about, but a little
code duplication seemed a lot better than trying to unify the code
in two very different places.
I think we're very close to being able to assert that pack expansion
shapes are either pack archetypes or pack parameters; unfortunately,
the pack matchers intentionally produce expansions of packs, and I
didn't want to add that to an already-large patch.
* Argument to '-load-plugin-library' now must have a filename that's
'{libprefix}{modulename}.{sharedlibraryextension}'
* Load '-load-plugin-library' plugins are now lazily loaded in
'CompilerPluginLoadRequest'
* Remove ASTContext.LoadedSymbols cache because they are cached by
'ExternalMacroDefinitionRequest' anyway
* `-load-plugin-executable` format validation is now in
'ParseSearchPathArgs'
This executable is intended to be installed in the toolchain and act as
an executable compiler plugin just like other 'macro' plugins.
This plugin server has an optional method 'loadPluginLibrary' that
dynamically loads dylib plugins.
The compiler has a newly added option '-external-plugin-path'. This
option receives a pair of the plugin library search path (just like
'-plugin-path') and the corresponding "plugin server" path, separated
by '#'. i.e.
-external-plugin-path
<plugin library search path>#<plugin server executable path>
For exmaple, when there's a macro decl:
@freestanding(expression)
macro stringify<T>(T) -> (T, String) =
#externalMacro(module: "BasicMacro", type: "StringifyMacro")
The compiler look for 'libBasicMacro.dylib' in '-plugin-path' paths,
if not found, it falls back to '-external-plugin-path' and tries to find
'libBasicMacro.dylib' in them. If it's found, the "plugin server" path
is launched just like an executable plugin, then 'loadPluginLibrary'
method is invoked via IPC, which 'dlopen' the library path in the plugin
server. At the actual macro expansion, the mangled name for
'BasicMacro.StringifyMacro' is used to resolve the macro just like
dylib plugins in the compiler.
This is useful for
* Isolating the plugin process, so the plugin crashes doesn't result
the compiler crash
* Being able to use library plugins linked with other `swift-syntax`
versions
rdar://105104850
opened generic environments
Finding these is very hot for these environments, so doing it once
is a pretty nice win in both speed and code complexity.
I'm not actually using this yet.
Enforce that we don't have any type variables
present in either the result or parameter types.
To ensure the constraint system doesn't violate
this invariant, refactor `getTypeOfMemberReference`
slightly to avoid construction of a
`GenericFunctionType` as a means of opening the
generic parameters of the context for a VarDecl.
element environments.
This allows the constraint system to ensure that for a given pack expansion locator,
the given shape class is always the same when requesting the element environment.
If the shape class differs, it means there's a same-shape requirement failure, which
will be diagnosed via the ShapeOf constraint simplification.
When loading plugins from `-plugin-path`, use the global `PluginRegistry` to keep a record of what's loaded. Emit these dependencies to the loaded module trace.
This required quite a bit of infrastructure for emitting this kind of
tuple expression, although I'm not going to claim they really work yet;
in particular, I know the RValue constructor is going to try to explode
them, which it really shouldn't.
It also doesn't include the caller side of returns, for which I'll need
to teach ResultPlan to do the new abstraction-pattern walk. But that's
next.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::optional` when used from Swift code.
As of now, the overlay adds an initializer of `Swift.Optional` that takes an instance of `CxxOptional` as a parameter.
`__shared` and `__owned` would always get mangled, even when they don't have any effect
on ABI, making it unnecessarily ABI-breaking to apply them to existing API to make
calling conventions explicit. Avoid this issue by only mangling them in cases where they
change the ABI from the default.
