Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
"Support Macros in Linux" patches was inconsistent with checking
platforms. Some only checked 'LINUX' but some matches
'LINUX|ANDROID|OPENBSD|FREEBSD'. Although I don't have tested other
platoforms than Linux at all, there's no reason to limit it to Linux.
So use the consistent check to match 'LINUX|ANDROID|OPENBSD|FREEBSD'
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
* [Observation] Forward availability and defines to extensions
* Simplify availability slightly from review feedback
* Simplify availability for extensions to use `.with`
This adopts `@attached(peer)` for generating an observable type's
underscored storage when expanding the `@ObservationTracked` macro,
instead of using `arbitrary` with the member macro on the
observable type.
With support for redundant conformance declarations via macros,
the `Observable` protocol can be a non-marker protocol, which
provides more flexibility for evolution in the future.
rdar://111463883
This change also switches to the new ExtensionMacro protocol,
the requirement for which includes information about whether the
conformance to the Observable protocol has already been added, either
in the declaration or in a superclass to the macro-attributed type.
This allows the @Observable macro to be applied to subclasses of
observable types without redundant-conformance errors.
* Make ObservationRegistrar Codable/Hashable
These conformances enable automatic Codable synthesis for Observable
types, and smooth the runway for structs being supported by the
Observable macro in the future.
* Limit Observable macro to classes
This removes the ability for the Observable macro to apply to structs,
and adds diagnostic tests for the three disallowed declaration kinds.
The review of SE-0395 is down to small details at this point that won't
affect the overall shape of the API much. Rename the model in
anticipation of that.
* [Observation] Transition to peer macros instead of arbitrary members
* [Observation] Lift the initializer requirement by utilizing init accessors for fully formed definite initialization
* [Observation] Gate enabling of peer macros by flag
* [Observation] Enable feature for InitAccessors in the observation tests
* [Observation] Add tests to validate memberwise and definite initialization
* [Observation] Change visibility of observation runtime functions to be hidden
* [Observation] Update API requirements for Observable AsyncSequence names and alter the behavior of value emissions to be based upon transactionality
* [Observation] Slight naming alteration of isolation -> isolatedTo
Note: This re-enables the previously disabled tests since the implementation should be considerably more robust to hangs.
* Move `add_pure_swift_host_library()` from lib/CMakeLists.txt to
AddPureSwift.cmake so that code outside `lib` can use it
* Add `add_pure_swift_host_tool()` function to make a pure Swift
host executable target (for future usages)
* Specify depending `SwiftSyntax` modules explicitly because not all
Swift libraries uses all SwiftSyntax libraries
The dependency of the Observation library on the observation macro
plugin introduces a direct dependency of a target library on a host
library, (lib -> stdlib) that we'd like to avoid. Instead, make the
Swift frontend binary depend on the macro plugin libraries that we
build, so that it's the complete host-side stack.
Refactor the build support for ASTGen and ObservationMacros. Both have
nearly-identical copies of a bunch of messy, workaround-laden CMake
code to build "pure" Swift host libraries using CMake's Swift support.
Instead, introduce `add_pure_swift_host_library` to centralize all of
the hacks to build a host library that's all Swift, using CMake's
support directly (rather than custom commands), and link against the
swift-syntax stack. Switch ASTGen directly over to this.
Add `add_swift_macro_library` on top of this, to make it easy to
create a macro library and install it into the appopriate plugin
directory. Switch ObservationMacros over to this.
