Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
There is no `%swift-frontend-target` subsitution in test, which is
actually `%target-swift-frontend`. The wrong spelling is actually
interpreted by lit as `%swift`-frontend-target, and surprising didn't
break any tests as the last argument from subsitution is
`-define-availability` so it just leads to an very akward availability
definition.
Instead of emitting an warning to the diagnostic engine, return the
plugin loading error as the result of the request. So that the user
can decide to emit it as a warning or an error.
Macro implementations can come from various locations associated with
different search paths. Add a frontend flag `-Rmacro-loading` to emit
a remark when each macro implementation module is resolved, providing
the kind of macro (shared library, executable, shared library loaded
via the plugin server) and appropriate paths. This allows one to tell
from the build load which macros are used.
Addresses rdar://110780311.
* Move collapse(expansions:for:attachedTo:) to SwiftSyntaxMacroExpansion
* SwiftSyntaxMacroExpansion.expandAttachedMacro() now perform collapsing
* SwiftSyntaxMacroExpansion.expandAttachedMacroWithoutCollapsing()
to keep old behavior
* IPC request 'getCapability' now sends the host protocol version
* Unified IPC response 'macroExpansionResult' that returns single string
for both 'expandFreestandingMacro' and 'expandAttachedMacro'
* Compiler accepts old 'expandFreestandingMacroResult' and
'expandAttachedMacroResult' to keep compatibility
* Plugins check the compiler's protcol version to see if it suppports
'macroExpansionResult', and fall back to old behavior if necessary
The compiler knows (from a macro declaration) what freestanding macro
role a macro implementation is expected to implement. Pass that through
to the macro expansion code itself, rather than guessing based on the
protocol conformances of the implementation type. We already use this
approach with attached macros, so this is more of the same.
Eliminates a crash and improves diagnostics when the freestanding macro
role and its implementation are out of sync, fixing rdar://110418969.
The macro tests were all using "REQUIRES: OS=macosx" as a proxy for
"have the Swift Swift parser". There was an existing feature for this,
but it was just checking whether the path was passed through. Fix that
to use the same variable as in CMake.
Also remove all extraneous `-I` and `-L` to the host libs in the target
invocations.
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
