Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
Some places want to do in-order walks of MacroExpansionDecls, but still
visit auxiliary declarations. Rather than force them to specifically
filter out declarations from the MacroExpansionDecl, add a parameter to
visitAuxiliaryDecls to skip them.
'MacroExpansionDecl' and 'MacroExpansionExpr' have many common methods.
Introduce a common base class 'FreestandingMacroExpansion' that holds
'MacroExpansionInfo'.
Factor out common expansion logic to 'evaluateFreestandingMacro'
function that resembles 'evaluateAttachedMacro'.
Keep track of which types/extensions have members that could be produced by
a macro expansion, including the names of those members. Use this to
avoid walking into extensions or type definitions to expand macros
when they don't have any related macros.
Setting closure and local discriminators depends on an in-order walk
of the AST. For macros, it was walking into both macro expansions and
arguments. However, this doesn't work well with lazy macro expansions,
and could result in some closures/local variables not getting
discriminators set at all.
Make the assignment of discriminators only walk macro arguments, and
then lazily assign discriminators for anything within a macro
expansion or in ill-formed code. This replaces the single global "next
autoclosure discriminator" scheme with a per-DeclContext scheme, that
is more reliable/robust, although it does mean that discriminators
of closures and locals within macro expansions are dependent on
ordering. That shouldn't matter, because these are local values.
Fixes rdar://108682196.
Type-checking an operator requires look up of all of its decls regardless of
which access modifier is used before filtering. If one of them is a package
decl in an imported module that was built with package-name, but the use site
of the operator decl is in a module that is not built with package-name, it
currently crashes as it tries to access package context of the use site, which
is null. This PR checks if both decl site and use site have package contexts
before accessing the package name property, otherwise return false to be filtered
out.
Resolves rdar://108961906
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.
We need to teach code completion how to invoke the type checker for attached macro attributes. After that, everything started working.
rdar://105232015
Attached macro mangles for accessors were using a fallback case that
triggers an assertion in +Asserts builds, and conflicting manglings is
non-Asserts builds. Provide a custom mangling for these cases that's
embedded in the identifier.
This is a narrow hack to eliminate an assertion. We are considering a
different approach for the long term that uses entity manglings with a
placeholder type, which will be more flexible long-term.
We were not type checking the default argument initializer because `MacroDecl` is not an `AbstractFucntionDecl`. Add `MacroDecl` to the list of nodes we know how to get parameters from.
rdar://108163564
When completing after `names:`, completion should offer the different ways you can specify the names, i.e. `arbitrary`, `named`, etc.
```
@freestanding(declaration, names: #^COMPLETE^#)
```
rdar://108535077
When an accessor macro adds a non-observing accessor to a property, it
subsumes the initializer. We had previously modeled this as removing
the initializer, but doing so means that the initializer could not be
used for type inference and was lost in the AST.
Explicitly mark the initializer as "subsumed" here, and be more
careful when querying the initializer to distinguish between "the
initializer that was written" and "the initializer that will execute"
in more places. This distinction already existed at the
pattern-binding level, but not at the variable-declaration level.
This is the proper fix for the circular reference issue described in
rdar://108565923 (test case in the prior commit).
Eliminate another circular reference through macro expansion mangling
by adjusting the starting declaration context to ensure that it is from
a suitable "outer" context.
Fixes rdar://108511666.
My recent change to parse initializer names in the macro role
introduced names now correctly distinguishes between the two forms, but
this breaks any existing macros written with the back-ticked form.
Treat the former as the latter to provide a grace period for such
macros.
Fixes rdar://108571834.
The macro-resolution request for an attached macro was expressed in
terms of the custom attribute and the declaration context enclosing the
attribute. While the declaration context is the correct one for
resolving the types and arguments of the custom attribute, the
declaration provides a better anchor for cases where the same
attribute applies to multiple declarations, e.g., with
member-attribute macros, leading to false cyclic references.
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.
If a parameter is marked consuming and its type is Copyable, that
parameter has eager-move semantics. Apply that attribute to the
SILFunctionArgument corresponding to the parameter.
rdar://108385761
Parse compound and special names in the macro role attributes
(`@freestanding` and `@attached`). This allows both compound names and
initializers, e.g., `init(coding:)`.
Fixes rdar://107967344.
This method was misleading. The majority of callers (all but one!) don't want
to unconditionally treat all locations in any macro expansion buffer the
same way, because the code also must handle nested macro expansions. There
is one part of SourceKit (and possibly others) that really do want to ignore
all macro expansions, but those can be handled within SourceKit / IDE code,
because I don't believe this utility is useful in the frontend.
inside closures while type checking a macro expansion.
PreCheckExpr, ConstraintGenerator, and other walkers do not walk into macro
expansions. However, the implementation of this macro walking behavior in
ASTWalker would skip any declaration that appears inside any macro expansion
buffer. This is incorrect for cases where the parent is in the same macro
expansion buffer, because the local declaration is not inside a new macro
expansion. This caused bogus errors when type checking expanded macro expressions
containing closures with local declarations, because pre-check and constraint
generation mistakenly skipped local pattern bindings.
