Macro-generated extensions are hoisted to file scope, because extensions are
not valid in nested scopes. Callers of 'visitAuxiliaryDecls' assume that the
auxiliary decls are in the same decl context as the original, which is clearly
not the case for extensions, and it leads to issues like visiting extension at
the wrong time during SILGen. The extensions are already added to the top-level
decls, so we don't need to visit them as auxiliary decls, and we can type-check
macro-expanded decls at the end of visitation in TypeCheckDeclPrimary.
Teach `getTopLevelDeclsWithAuxiliaryDecls` not to provide extension
declarations, because those are covered by the synthesized file, which
all clients need to walk anyway. Without this, we end up asserting in
TBD generation about duplicate symbol visitation.
Encountered while investigating rdar://108056018.
When expanding a conformance macro, the generated extension decls are added to
the TopLevelDecls vector of the synthesized file unit to expose them to
sf->getSynthesizedFile()->getTopLevelDecls(). There are two problems with this:
1. These decls are also visited via visitAuxiliaryDecls() for the purpose of
type checking. This causes problems in code generation because the extensions
are visited separately, and because SIL and IRGen assume nested auxiliary decls
are members.
2. SILGen only emits top-level decls directly from the source file rather than its
synthesized file. Auxiliary decls are visited here, but this doesn't work for
nested conformance macros because the attached-to decl is not at the top-level,
so macro-generated conformances for nested types never emit their descriptor.
To fix this in the short term, visit top-level decls in the synthesized file that are
generated by conformance macros, and skip auxiliary extension decls when emitting type
members. This fix is narrowly scoped to only impact macros, but in the future this
warrants a more structural fix to better handle top-level decls in the synthesized file.
The mangling of attached macro expansions based on the declaration to
which they are attached requires semantic information (specifically,
the interface type of that declaration) that caused cyclic
dependencies during type checking. Replace the mangling with a
less-complete mangling that only requires syntactic information from
the declaration, i.e., the name of the declaration to which the macro
was attached.
This eliminates reference cycles that occur with attached macros that
produce arbitrary names.
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.
When we form an extension for a conformance macro, make sure to
register that extension as being part of the nominal type to which the
conformance macro is attached. This ensures that the conformance is
seen everywhere. Crucially, this ensures that that protocol
conformance table handles conformances that are implied by the
conformance macro. For example, a conformance macro that introduces a
`Hashable` conformance will also imply an `Equatable` conformance;
that wasn't happening before this change.
This is needed to make the `OptionSet` macro work fully.
