Ensure we always expand extension macros after the top-level decl
for the given attached decl. This ensures correct unqualified lookup
behavior, and bans macro implementations from extending the
unqualified name (they're expected to use `providingExtensionsOf`
instead, which uses the qualified name).
rdar://148119538
Sendable conformances outside the defining source file.
This allows macros to add a Sendable conformance when the macro is applied
in the same source file as the primary declaration.
Pre-macro-expansion conformances are introduced at the point where an
attached extension macro is attached to a particular nominal type, and
can imply other conformances. Once the macro is expanded, they are
expected to be replaced by the real conformance from the extension
produced by the macro. This includes any other conformances that are
implied by that conformances. Ensure that the real conformance---and
every conformances it implies---are considered "better" than the
pre-expansion conformances.
Fixes a bug where we would pick the wrong (pre-expansion)
conformances, which would then fail to get fully type-checked prior to
serialization. This could accept invalid code that then crashed the
compiler, as in rdar://112916159.
Fix two inter-related issues with extension macros that provide
conformances to a protocol, the combined effect of which is that one
cannot meaningfully provide extension macros that implement
conformances to a protocol like Equatable or Hashable that also
supports auto-synthesis.
The first issue involves name lookup of operators provided by macro
expansions. The logic for performing qualified lookup in addition to
unqualified lookup (for operators) did not account for extension
macros in the same manner as it did for member macros, so we would not
find a macro-produced operator (such as operator==) in witness
matching.
The second issue is more fundamental, which is that the conformance
lookup table would create `NormalProtocolConformance` instances for
pre-macro-expansion conformance entries, even though these should
always have been superseded by explicit conformances within the macro
expansion buffers. The end result is that we could end up with two
`NormalProtocolConformance` records for the same conformance. Some
code was taught to ignore the pre-expansion placeholder conformances,
other code was not. Instead, we now refuse to create a
`NormalProtocolConformance` for the pre-expansion entries, and remove
all of the special-case checks for this, so we always using the
superseding explicit conformances produced by the macro expansions (or
error if the macros don't produce them).
Fixes rdar://113994346 / https://github.com/apple/swift/issues/66348
This could also use `%kind` for the declaration kind, but that ends up
being "extension of struct" instead of just "extension", which seems
slightly worse.
Use the attached atttribute's location as the location of the macro,
rather than the location of the declaration it's attached to. Also add
the kind and name of that declaration to the note itself.
stated in the original source.
If an extension macro can introduce protocol conformances, macro expansion
will check which of those protocols already have a stated conformance in the
original source. The protocols that don't will be passed as arguments to
extension macro expansion, indicating to the macro that it should only add
conformances to those protocols.
