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.
UnqualifiedLookupRequest takes a DeclContext and a SourceLoc. If the
SourceLoc is valid, it locates the innermost ASTScope containing this
location, and starts the lookup from that scope.
Also, ASTScope currently walks up the scope tree to find the
innermost scope that corresponds to the given DeclContext, in case
the DeclContext is a parent of the 'natural' DeclContext for this
source location.
We want to remove this additional behavior and make ASTScope only
depend on a source file and source location.
This requires changing directReferencesForUnqualifiedTypeLookup()
to handle the top-level lookup case explicitly. See the comment for
more details.
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.
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
Call prepareExtensions to make sure we load in any
new extensions brought in by modules loaded
after-the-fact. This isn't an issue for normal
compilations as we load all the modules up-front
in import resolution, but clients such as the
LLDB REPL may load in modules later.
Resolves rdar://64040436.
Resolve the written type instead of the semantic type since that's the only data these requests will have access to once RequirementRepr is made completely syntactic.
Previously, whenever name lookup returned two declarations with the same
name, we would compute the canonical type of each one as part of the
shadowing check.
The canonical type calculation is rather expensive for GenericFunctionTypes
since it requires constructing a GenericSignatureBuilder to canonicalize
type parameters that appear in the function's signature.
Instead, let's first shard all declarations that have the same name by
their generic signature. If two declarations have the same signature, only
then do we proceed to compute their canonical type.
Since computing a canonical GenericSignature is cheaper than computing a
canonical GenericFunctionType, this should speed up name lookup of
heavily-overloaded names, such as operators.
Fixes <rdar://problem/56800097>.
Add overloads of `removeShadowedDecls` that deal
with operator and precedencegroup decls, and
template the existing shadowing logic such that it
can process them.
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
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.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
Make configureLookup a little easier to reason about by pushing the read
of this flag down into lookup instead of mutating the lookup flags
beforehand.
Replace it with the "legacy semantic queries" bit. The remaining client
of this bit is SourceKit, which appears to require this bit be set
conditionally so certain semantic property wrapper requests return
a sentinel value.
We should migrate these requests to a syntactic interface as soon as
possible.
rdar://60516325
Revert the property wrappers part of dd51251014.
Every part of the qualified lookup stack needs to synthesize property
wrapper members, otherwise we'll be subject to the relativistic effects
of semantic lookups in different files. Besides, Codable was the main
source of cycles and circularity under the old scheme.
Resolves rdar://59531889
Effectively revert #28907. The request evaluator will also catch re-entrancy here, and those cycles can be broken with NameLookupFlags::IgnoreNewExtensions.
Soft revert a09382c. It should now be safe to add this flag back as an optimization to specifically disable lazy member loading instead of all extension loading.
Push the flag back everywhere it was needed, but also push it into lookup for associated type members which will never appear in extensions.
