Rather than requiring macro implementations to add required whitespace
and indentation, basic format all macro expansions. Right now this uses
the default four space indentation, we can consider having that inferred
later. Macros can opt-out of automatic formatting by implementing
`formatMode` and setting it to `.disabled`.
Also moves the extra newlines before/after expansions to a new "Inline
Macro" refactoring.
Resolves rdar://107731047.
The request returns the expanded buffer ID even if it failed to
typecheck the expanded buffer.
This makes refactoring 'Expand Macro' work regardless of the
typechecking results.
rdar://108530760
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.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
Pass back the original location (ie. where the macro was expanded, not
the location that the generated code would be inserted) for cursor info
and indexing. Also mark any declarations/references within generated
source as implicit.
Resolves rdar://107209132.
Update requests to handle being passed a separate `key.primary_file`
which specifies the file to use for building the AST. `key.sourcefile`
is then the file to find in `SourceManager`, which could be a generated
buffer.
Resolves rdar://106863186.
Rather than editing the macro buffer in refactoring, add appropriate
padding and braces when creating the macro.
Don't edit the insertion location - we should update this in a later PR
as well.
This adds a new `primary_file` key, which defaults to `sourcefile`. For
nested expansions, `primary_file` should be set to the containing file
and `sourcefile` to the name of the macro expansion buffer.
Add two new fields to refactoring edits:
- A file path if the edit corresponds to a buffer other than the
original file
- A buffer name when the edit is actually source of generated buffer
Macro expansions allow the former as a macro could expand to member
attributes, which may eg. add accessors to each member. The attribute
itself is inside the expansion, but the edit is to the member in the
original source.
The latter will later allow clients to send requests with these names to
allow semantic functionality inside synthesized buffers.
Various requests expect to be walking over the current source file.
While we could add checks to all these to skip decls outside of the
current buffer, it's a little nicer to handle this during the walk
instead.
Allow ignoring nodes that are from macro expansions and add that flag to
the various walks that expect it.
Also add a new `getOriginalAttrs` that filters out attributes in
generated source.
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.
Extend the macro-expansion refactoring to work with member and
member-attribute attached macros. These expansions can return several
different changes, e.g., adding new members, sprinkling member
attributes around, and so on.
- Use the name lookup table instead of adding members from a macro expansion to the parent decl context.
- Require declaration macros to specify introduced names and used the declared names to guide macro expansions lazily.
