This includes changing the feature name so that compilers with the experimental feature don’t accidentally pick up content that only works in the final version.
Resolves rdar://150065196.
Since the introduction of custom attributes (as part of property
wrappers), we've modeled the context of expressions within these
attributes as PatternBindingInitializers. These
PatternBindingInitializers would get wired in to the variable
declarations they apply to, establishing the appropriate declaration
context hierarchy. This worked because property wrappers only every
applied to---you guessed it!---properties, so the
PatternBindingInitializer would always get filled in.
When custom attributes were extended to apply to anything for the
purposes of macros, the use of PatternBindingInitializer became less
appropriate. Specifically, the binding declaration would never get
filled in (it's always NULL), so any place in the compiler that
accesses the binding might have to deal with it being NULL, which is a
new requirement. Few did, crashes ensued.
Rather than continue to play whack-a-mole with the abused
PatternBindingInitializer, introduce a new CustomAttributeInitializer
to model the context of custom attribute arguments. When the
attributes are assigned to a declaration that has a
PatternBindingInitializer, we reparent this new initializer to the
PatternBindingInitializer. This helps separate out the logic for
custom attributes vs. actual initializers.
Fixes https://github.com/swiftlang/swift/issues/76409 / rdar://136997841
The insertion position of member-attribute macros was right before the
first attribute. However, ASTScope would visit the as-written attributes
first, so the scope tree entries would be out of order, causing name
lookup to fail.
Move the insertion position to where a new modifier would go, i.e.,
after the explicitly-written attributes. Fixes rdar://120496864.
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.
names at global scope.
Freestanding and peer macros applied at top-level scope cannot introduce
arbitrary names. Introducing arbitrary names means that any lookup
into this scope must expand the macro. This is a problem, because
resolving the macro can invoke type checking other declarations, e.g.
anything that the macro arguments depend on. If _anything_ the macro
depends on performs name unqualified name lookup, e.g. type resolution,
we'll get circularity errors. It's better to prevent this by banning
these macros at global scope if any of the macro candidates introduce
arbitrary names.
Calling `getInnermostDeclContext()->getParentSourceFile()` on a macro-produced decl does not seem to be a reliable way to obtain the macro expansion source file, because `PatternBindingDecl` is not a `DeclContext` and `getInnermostDeclContext()` falls back outside the macro expansion file. This patch switches to using `getSourceFileContainingLocation` when possible.
Resolves rdar://109376568.
Make sure we walk auxiliary declarations when gathering stored
properties. This ensures that we will get any stored properties
introduced by peer macros.
Fixes rdar://108534298.
The last step in breaking the cycle through visible declaration lookup,
e.g., with invalid code. Prior to this, we would get a false cyclic
reference through the parameters of a function when they try to find
property wrappers on the parameters.
This cycle break means that some attributes introduced by
member-attribute macros aren't getting processed. I'm still reducing a
test case while I look for a fix, but for now I'm reverting this
change to address a regression for macros.
Fixes rdar://108456284.
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.
When we look into expanded macros to find declarations for module-scope
name lookup, make sure that we only return declarations whose name
matches the requested name.
We were effectively spamming the results with unrelated names, and
most clients trust the results of this lookup (vs. filtering them
further), so they would get confused. The particular failure for this
test is that type reconstruction would fail because we were looking
for one unique name, but we found many non-matching names, and type
reconstruction bails out rather than try to filter further.
To ensure that class vtables get laid out with the right ABI, visiting
a class declaration visits all of its "ABI members", which includes
visiting all of the auxiliary declarations. However, we also visit the
auxiliary declarations of every declaration, which means some
declarations get visited twice.
This led to another oddly-specific bug for macros, where we would
visit declarations introduce by peer macros on class members twice.
When combined with function-body-skipping (e.g., to emit a module
file), this would result in spurious errors of the form:
Expected '{' in body of function declaration
Stop visiting the auxiliary declarations of class members twice,
eliminating this error. This one has been annoying me off and on for a
while :).
Fixes rdar://107429169.
Peer macro produce declarations that are semantically alongside the
declaration to which the macro is attached. However, the source
location used for constructing the scope tree was based on the
attribute itself, which meant it was inside the scope of the
declaration to which the macro was attached. This lead to incorrect
unqualified name lookup; in the example that's now a test case, this
meant that the `Self` of the protocol to which the macro was attached
was visible from within the peer declaration. Hilarity (in the form of
a type checker crash) ensued.
Fix the location used for constructing the scope tree of peer macros to
be right after the attached declaration. Fixes rdar://107228586.
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.
The macro name resolution in the source lookup cache was only looking at
macros in the current module, meaning that any names introduced by peer
or declaration macros declared in one module but used in another would
not be found by name lookup.
Switch the source lookup cache over to using the same
`forEachPotentialResolvedMacro` API that is used by lookup within
types, so we have consistent name-lookup-level macro resolution in both
places.
... except that would be horribly cyclic, of course, so introduce name
lookup flags to ignore top-level declarations introduced by macro
expansions. This is semantically correct because macro expansions are
not allowed to introduce new macros anyway, because that would have
been a terrible idea.
Fixes rdar://107321469. Peer and declaration macros at module scope
should work a whole lot better now.
When populating the name lookup tables for a nominal type, we were only
visiting declarations with peer macros within the nominal type
declaration itself. Also visit the members of extensions of the
nominal type.
Without this change, peer-macro-defined members of extensions are not
visible.
Always use `Decl::visitAuxiliaryDecls` to visit decls produced by macros, including peer macros and declaration macros. Use name-driven expansion for peer macros. Remove `MacroExpansionDecl::getRewritten()`.
Also make `ExpandMacroExpansionDeclRequest` cache the buffer ID (similar to other macros) instead of an array of decls.
Global peer macro expansions are not injected into the AST. Instead, they
are visited as "auxiliary declarations" when needed, such as in the decl
checker and during SILGen. This is the same mechanism used for local property
wrappers and local lazy variables.
