* Don't invalidate the lookup cache in 'getOrCreateSynthesizedFile()'
Adding a synthesized file itself doesn't introduce any decls. Instead,
we should invalidate the right after the actual declrations are added
in the file
* Remove 'SourceLookupCache::invalidate()' method. It was just used
right before the destruction. It was just not necessary
* Include auxiliary decls in 'SourceLookupCache::lookupVisibleDecls()'
Previously, global symbol completion didn't include decls synthesized
by peer macros or freestanding decl macros
* Include "auxiliary decls" in visible member lookup, and visible local
decl lookup
* Hide macro unique names
rdar://110535113
When an `OpaqueTypeDecl` is constructed, the access level attributes of the
decl that names the opaque type were copied on to it. However, the
`@usableFromInline` attribute is not permitted on every decl, so it does not
get copied. This in turn causes access level computations for opaque types to
fail to take `@usableFromInline` into account and that results in the emitted
symbol getting the wrong linkage during IRGen. The fix is to make access level
computations take this quirk of opaque types into account directly (like they
already to for several other kinds of decls), instead of relying on copying of
attributes.
Resolves rdar://110544170
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
The `hasStorage()` computation is used in many places to determine the
signatures of other declarations. It currently needs to expand accessor
macros, which causes a number of cyclic references. Provide a
simplified request to determine `hasStorage` without expanding or
resolving macros, breaking a common pattern of cycles when using
macros.
Fixes rdar://109668383.
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.
