We have two "levels" of name lookup, and the more primitive level is
used by name lookup itself to avoid certain cycles. For example,
extension binding, resolution of inheritance clauses, etc.
One interesting case is that a protocol extension can impose additional
requiremnts on `Self`, and members of the right-hand side type are
visible to unqualified lookup.
The right-hand side of a `Self` requirement in this case is always a
protocol type or class type canonically, but it might be written to
refer to a protocol type alias.
Before some changes for noncopyable generics, the primitive name
lookup mechanism, implemented in directReferencesForTypeRepr() and
such, would check if the TypeRepr had already been resolved by
resolveType(). If so, it would immediately return the decl.
This masked an issue, where the right-hand side of a `Self` requirement
was resolved in the parent DeclContext. A more subtle rule is needed;
for a protocol extension, we must resolve the right-hand side in the
protocol, but disregard the protocol extension's `Self` requirements,
because doing so would recursively trigger the same lookup again.
Fixes rdar://problem/124498054.
In rdar://123649082, a project failed to build because of the lazy import-as-member loading changes in #71320. That project was configured in a way that broke modularization and the correct solution is to fix it, but out of an abundance of caution, add a `-disable-named-lazy-import-as-member-loading` frontend flag in case a project needs to temporarily restore the old behavior.
As a bonus, this lets us write a test to verify that lazy import-as-member loading has positive performance impact.
If an extension isn't imported either directly or via a transitive
(`@_exported`) import, its members should not be visible to name
lookup. Implement this behavior behind the experimental flag
ExtensionImportVisibility.
Previously, if a request R evaluated itself N times, we would emit N
"circular reference" diagnostics. These add no value, so instead let's
cache the user-provided default value on the first circular evaluation.
This changes things slightly so that instead of returning an
llvm::Expected<Request::OutputType>, various evaluator methods take
a callback which can produce the default value.
The existing evaluateOrDefault() interface is unchanged, and a new
evaluateOrFatal() entry point replaces
llvm::cantFail(ctx.evaluator(...)).
Direct callers of the evaluator's operator() were updated to pass in
the callback. The benefit of the callback over evaluateOrDefault() is
that if the default value is expensive to constuct, like a dummy
generic signature, we will only construct it in the case where a
cycle actually happened, otherwise we just delete the callback.
(cherry picked from commit b8fcf1c709efa6cd28e1217bd0efe876f7c0d2b7)
Both `try?` and `try!` are catch nodes, because they catch an error
thrown in their subexpression and handle it. Introduce an ASTScope for
all `try/try?/try1` expressions so we can find them, and model them as
catch nodes.
Fixes rdar://119216455.
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.
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.
Check accessibility of all build{Partial}Block overloads and
diagnose if none of them are as accessible as type, otherwise
swift interfaces could end up with invalid result builder
declarations when type is public and all builder methods are
internal.
Resolves: rdar://104384604
Now that directReferencesForTypeRepr() no longer returns
ambiguous results, move the special ambiguity diagnostic out
of CustomAttrNominalRequest::evaluate(), and instead
diagnose these situations in TypeCheckAttr.cpp.
Special-case the 'unknown type' diagnostic though, to report
'unknown attribute' in the common case where the name lookup
failed.
Instead of failing constraint generation upon encountering
an invalid declaration, let's turn that declaration into a
potential hole and keep going. Doing so enables the solver
to reach a solution and diagnose any other issue with
expression.
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
The top-level scope for a conditional clause with a pattern is now
ConditionalClausePatternUseScope, which introduces the pattern's
bindings.
Since the patterns are not visible in their own initializer, a new
ConditionalClauseInitializerScope is used for the initializer.
While it is nested inside of the ConditionalClausePatternUseScope,
it's lookup parent skips one level, giving us the desired behavior.
Before performing an UnqualifiedLookup with Flags::IncludeOuterResults
turned on, call ASTScope::lookupSingleLocalDecl() to find local
bindings that precede the current source location.
If this fails, we perform an unqualified lookup to try to find
forward references to captures, type members, and top-level
declarations.
This gives us the desired behavior, where local bindings are in
scope after their definition.
Note that BraceStmt still introduces all bindings at the beginning,
but now we change BraceStmt to only introduce local functions and
types, allowing us to disable parse-time lookup.
Private imports are intended to make the file performing the import more or less source-compatible with the file being imported from, so that code from the original file can be modified by relatively simple syntactic transformations. However, their name shadowing behavior was very different from the original file. In the original file, other declarations in the same module would have shadowed declarations imported from any other module; in a file using a @_private import, they would all be considered imports, and thus all would be preferred equally. This could cause ambiguity in a file using a @_private import that was not present in the original file.
This commit changes that behavior by favoring @_private imports over other imports, so that if a name is visible through both a private and a non-private import, the one visible through the private import will shadow the other. This shadowing takes a higher priority than a scoped import, but a lower priority than the check for whether one of the modules is only visible through the other.
Fixes rdar://68312053.
This centralizes some invariants around the 'self' parameter.
While all ConstructorDecls and DestructorDecls have a 'self',
even if they're invalid because they're not nested inside a type,
we don't want to consider this as the base 'self' for lookups.
Eg, consider this invalid code:
class C {
func f() {
init() {
x
}
}
}
The base for the lookup should be f.self, not f.init.self.
TypeChecker::lookupMemberType() performs a lookup on the base type,
and disambiguates multiple results by filtering out result decls
that have canonically equal types under the base type substitution.
I'd like to refactor conformance checking to call lookupQualified()
directly and bypass lookupMemberType(), but this requires adding a
new shadowing rule to primitive name lookup to simulate the effect
of the type-based disambiguation.
We already had a shadowing rule which states that concrete type
members shadow protocol members of the same name, but this was
bypassed for member _types_. This change generalizes this rule to
apply to member types also.
Hopefully this doesn't break source compatibility in practice.
This converts the path to use Unix path separators. This is required to
ensure that the `SOURCE_DIR` substitution works properly in the case
that the path uses mixed path separators.
Move reference dependency tests out of NameLookup and into
Incremental/Dependencies. These tests will need to be specialized for
the upcoming private dependencies code.
Convert most of the name lookup requests and a few other ancillary typechecking requests into dependency sinks.
Some requests are also combined sinks and sources in order to emulate the current scheme, which performs scope changes based on lookup flags. This is generally undesirable, since it means those requests cannot immediately be generalized to a purely context-based scheme because they depend on some client-provided entropy source. In particular, the few callers that are providing the "known private" name lookup flag need to be converted to perform lookups in the appropriate private context.
Clients that are passing "no known dependency" are currently considered universally incorrect and are outside the scope of the compatibility guarantees. This means that request-based dependency tracking registers strictly more edges than manual dependency tracking. It also means that once we fixup the clients that are passing "known private", we can completely remove these name lookup flags.
Finally, some tests had to change to accomodate the new scheme. Currently, we go out of our way to register a dependency edge for extensions that declare protocol conformances. However, we were also asserting in at least one test that extensions without protocol conformances weren't registering dependency edges. This is blatantly incorrect and has been undone now that the request-based scheme is automatically registering this edge.
The directory currently seems to have a mix of
tests for import resolution and name lookup.
Therefore split it into two directories;
ImportResolution and NameLookup.
