Unexpected warnings when capturing `self` in closures passed to macros

[NSFatalError]

Description

Any closure that captures self safely (including non-escaping closures and escaping closures marked with @_implicitSelfCapture) and is passed to a macro as its argument produces unexpected warnings, like:

Reference to property '...' in closure requires explicit use of 'self' to make capture semantics explicit; this will be an error in a future Swift language mode

or:

Call to method '...' in closure requires explicit use of 'self' to make capture semantics explicit; this will be an error in a future Swift language mode

Note: I've noticed this bug with freestanding expression macros specifically, but it's possible it affects other types as well.

Reproduction

import Testing

struct MyError: Error {}

struct MyStruct {
    func perform() throws {
        throw MyError()
    }
}

final class MyTests {
    let value = MyStruct()

    @Test func example() {
        #expect(throws: MyError.self) {
            try value.perform()
            // Reference to property 'value' in closure requires explicit use of 'self' to make capture semantics explicit;
            // this will be an error in a future Swift language mode
        }
    }
}

@freestanding(expression)
macro MyMacro(
    operation: () -> Void
) = #externalMacro(...)

class MyExample {
    func first() {
        #MyMacro {
            second()
            // Call to method 'second' in closure requires explicit use of 'self' to make capture semantics explicit; 
            // this will be an error in a future Swift language mode
        }
    }
    func second() {}
}

Expected behavior

Compiler applies the same rules for self capture in closures to macros as it does to standard functions.

Environment

swift-driver version: 1.120.5 Apple Swift version 6.1 (swiftlang-6.1.0.110.21 clang-1700.0.13.3)
Target: arm64-apple-macosx15.0

Note: this bug started occurring when updating to Xcode 16.3, it did not affect earlier 16.2 release.

Additional information

No response

[grynspan]

Neither this macro nor its implementation in Swift Testing marks the closure as @escaping, so it seems unlikely to be an issue on our side.