Throw an error if types conforming to MemberMacro implement no expansion method

When adding a new type that conforms to `MemberMacro`, no `expansion` function is required to be implemented. It’s necessary to do it this way because:

- `expansion(of:providingMembersOf:in:)` needs to exist as a protocol requirement to keep Swift 5.9 macros that implement this method compiling
- `expansion(of:providingMembersOf:in:)` needs to be defaulted so that macros implementing `expansion(of:providingMembersOf:conformingTo:in:)` don’t need to also provide an implementation for the legacy version that doesn’t have `conformingTo:`
- `expansion(of:providingMembersOf:conformingTo:in:)` obviously needs to exist since it’s the new dedicated entry point
- `expansion(of:providingMembersOf:conformingTo:in:)` needs to have a default implementation that calls `expansion(of:providingMembersOf:in:)` so that 5.9 macros continue to work
- We can’t mark `expansion(of:providingMembersOf:in:)` as deprecated because it’s called by the default implementation of `expansion(of:providingMembersOf:conformingTo:in:)` and we want to keep swift-syntax building without warnings.

At the moment, we provide default implementations for both `expansion` functions that call each other, which causes an infinite recursion, that makes it non-obvious to see what’s going wrong.

With this change, the default implementation of the legacy `expansion(of:providingMembersOf:in:)` method throws an error saying that you need to implement either of the two expansion methods. That way you get the following behavior:
- If you don’t implement either expansion function, the error gets thrown
- If a macro implements the legacy `expansion(of:providingMembersOf:in:)` function, then it overrides the throwing version and the macro works.
- If a macro implements the new `expansion(of:providingMembersOf:conformingTo:in:)` method, then the compiler calls into that method directly and the legacy `expansion(of:providingMembersOf:in:)` never gets invoked by the compiler.

The only possible issue I can think of is if a library is calling `expansion(of:providingMembersOf:in:)` but the macro only implements `expansion(of:providingMembersOf:conformingTo:in:)`. In this case an error would get thrown where it currently isn’t. But since I don’t see any reason why anyone would be calling `expansion(of:providingMembersOf:in:)` directly, I think this is fine.

Author: ahoppen

Sources/SwiftSyntaxMacros/MacroProtocols/MemberMacro.swift

@@ -23,7 +23,9 @@ public protocol MemberMacro: AttachedMacro {
   ///
   /// - Returns: the set of member declarations introduced by this macro, which
   /// are nested inside the `attachedTo` declaration.
-  @available(*, deprecated, message: "Use expansion(of:providingMembersOf:conformingTo:in:")
+  ///
+  /// - Warning: This is the legacy `expansion` function of `MemberMacro` that is provided for backwards-compatiblity.
+  ///   Use ``expansion(of:providingMembersOf:conformingTo:in:)-1sxoe`` instead.
   static func expansion(
     of node: AttributeSyntax,
     providingMembersOf declaration: some DeclGroupSyntax,
@@ -54,14 +56,24 @@ public protocol MemberMacro: AttachedMacro {
   ) throws -> [DeclSyntax]
 }
 
+private struct UnimplementedExpansionMethodError: Error, CustomStringConvertible {
+  var description: String {
+    """
+    Types conforming to `MemberMacro` must implement either \
+    expansion(of:providingMembersOf:in:) or \
+    expansion(of:providingMembersOf:conformingTo:in:)
+    """
+  }
+}
+
 public extension MemberMacro {
   /// Default implementation supplies no conformances.
   static func expansion(
     of node: AttributeSyntax,
     providingMembersOf declaration: some DeclGroupSyntax,
     in context: some MacroExpansionContext
   ) throws -> [DeclSyntax] {
-    return try expansion(of: node, providingMembersOf: declaration, conformingTo: [], in: context)
+    throw UnimplementedExpansionMethodError()
   }
 
   /// Default implementation that ignores the unhandled conformances.