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.
Previously, local optional binding values aren't suggested in subsequent
conditions in guard statement. That was because, if the condition
contains code-completion token, the parser stops parsing and add implicit
body with the end loc of the condition which is, in this case, the
position of the code-completion token. As a result, since code-completion
location is in the body range, namelookup::FindLocalVal refuses to emit
valuses in conditions.
This patch fixes the issue by ignoring implict body in `FindLocalVal`.
rdar://problem/28482216
Add a cache of lazily-imported names so we don't run off and deserialize extensions multiple times. The cache indicates that the lookup table has a complete understanding of any given base name. As a consequence, it must be flushed when a new extension with lazy members is added to avoid returning inconsistent results.
This should make lazy member cache misses much, much cheaper. In the best case, we'll avoid repeatedly crawling around on disk. In the average case, we'll have fallen off the lazy member loading path at some point for some extension and the lazily-complete cache will kick in to keep that one extension from pessimizing the rest. In the worst case - when an enormous amount of lookups for non-existent members occur - we'll probably balloon memory usage somewhat adding bogus members to the set.
Simplify lookupDirect to attempt one-shot name lookup based on some ideas Slava had. This means we'll try to perform a cache fill up front, then access the table rather than assuming the table is always (relatively) up to date and filling when we miss the first cache access.
This avoids a walk over the deserialized members of an extension that fails named lazy member loading. Instead, we eagerly page the members of the extension into the table and remove it from consideration for lazy member loading entirely.
In the future, we can convince the Clang Importer to avoid falling off the lazy member loading happy path.
This was just to confirm that the re-entrancy problem still exists on
the bots. There's something OS-dependent (probably the SDKs) that
causes this to only reproduce on 10.14.5 and not 10.15.
rdar://58116531
