The review of SE-0395 is down to small details at this point that won't
affect the overall shape of the API much. Rename the model in
anticipation of that.
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of https://github.com/apple/swift/issues/65726
Fixes: https://github.com/apple/swift/issues/64598
* 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
namespace.
This moves the `isInMacroArgument` predicate and `lookupMacros` into `namelookup`.
ASTScope still encapsulates the scope tree and contains the operation to lookup
the enclosing macro scope, which then invokes a callback to determine whether a
potential macro scope is indeed a macro, because answering this question requires
name lookup.
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.
Lazy member loading has been in use and the default for several years
now. However, the lazy loading was disabled for any type whose primary
definition was parsed even though some of its extensions could have
been deserialized, e.g., from a Clang module. Moreover, the non-lazy
path walked all of the extensions of such a type for all member name
lookup operations. Faced with a large number of extensions to the same
type (in my example, 6,000), this walk of the list of the extensions
could dominate type-checking time.
Eliminate all effects of the `-disable-named-lazy-member-loading`
flag, and always use the "lazy" path, which effectively does no work
for parsed type definitions and extensions thereof. The example with
6,000 extensions of a single type goes from type checking in 6 seconds
down to type checking in 0.6 seconds, and name lookup completely
disappears from the profiling trace.
The deleted tests relied on the flag that is now inert. They aren't by
themselves providing much value nowadays, and it's better to have the
simpler (and more efficient) implementation of member name lookup be
the only one.
Direct lookup relied in primary file checking to have filled in the
protocol type stored in the ImplementsAttr. This was already wrong
with multi-file test cases in non-WMO mode, and crashed in the
ASTPrinter if printing a declaration in a non-primary file.
I don't have a standalone test case that is independent of my
upcoming ASTPrinter changes, but this is a nice cleanup regardless.
Keep track of those types and extensions that have any macro expansions,
so that when we need to check whether to expand macros to satisfy name
lookup, we only look through that list---rather than looking at every
extension again.
This improves compile times significantly for a source file with a
large number of extensions on a single type. However, there is still
much to do here.
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.
An incorrectly-specified starting context for name lookup meant that
macro lookup itself was failing, and therefore did not trigger
expansion of the freestanding macro or introduction of the
macro-expanded declarations into the context.
Fixes rdar://108824784.
Eliminate a source of cyclic dependencies by not expanding macros when
we are resolving macro arguments within a type or extension context.
This extends the scheme introduced for module-scope lookup to also
apply to lookup within types.
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.
Some lookups, such as the ones used for protocol conformance checking,
provide full names (with arguments). Drop everything down to simple names
so they we don't skip macro expansions when we might need them.
When populating the name lookup tables with macro-expanded declarations,
we were careful to avoid full macro resolution for attached macros, but
freestanding macros were will doing full resolution. Switch
freestanding macros over to the same partial resolution mechanism to
avoid reference cycles.
Rather than eagerly expanding all member macros when doing any name
lookup into a type, use the same introduced-name-tracking logic we
apply to peer macros to only expand those member macros that can
produce the requested name. This makes the compiler lazier.
Ensure that name lookup triggers the expansion of member macros on
extensions, so we can find those names. And fix a bug that caused
expansion of member macros to crash.
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.
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
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.
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.
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
This lets us consolidate code paths that mostly run in parallel over the
existing InOutTypeRepr/SharedTypeRepr/OwnedTypeRepr family of types. This
patch by itself is NFC but makes it easier to introduce new spellings,
particularly the newly-official `borrowing` and `consuming` modifiers
that were approved in SE-0377.
The macro role argument presented an opportunity for callers to accidentally
invoke this request twice for the same macro with slightly different macro
roles passed in, which resulted in re-typechecking the macro arguments.
Instead, derive the corresponding macro roles from the macro reference syntax.
The result values of the expansion requests for attached macros tended
to be useless, because most of their operation is via side effects on
the nodes they are attached to. Replace the result values with an
array of expansion buffer IDs, so clients can see what effect the
macro expansion had.
- 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.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Macro attribute lookup is now implemented in ResolveMacroRequest, which happens
later because it needs overload resolution to resolve a custom attribute to a
macro decl.
