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
* WIP implementation
* Cleanup implementation
* Install backedge rather than storing array reference
* Add diagnostics
* Add missing parameter to ResultFinderForTypeContext constructor
* Fix tests for correct fix-it language
* Change to solution without backedge, change lookup behavior
* Improve diagnostics for weak captures and captures under different names
* Remove ghosts of implementations past
* Address review comments
* Reorder member variable initialization
* Fix typos
* Exclude value types from explicit self requirements
* Add tests
* Add implementation for AST lookup
* Add tests
* Begin addressing review comments
* Re-enable AST scope lookup
* Add fixme
* Pull fix-its into a separate function
* Remove capturedSelfContext tracking from type property initializers
* Add const specifiers to arguments
* Address review comments
* Fix string literals
* Refactor implicit self diagnostics
* Add comment
* Remove trailing whitespace
* Add tests for capture list across multiple lines
* Add additional test
* Fix typo
* Remove use of ?: to fix linux build
* Remove second use of ?:
* Rework logic for finding nested self contexts
The old name lookup would frequently try to flush and rebuild the name lookup cache. Instead, never flush the cache, and use the cache misses as an opportunity to load members and bring the lookup table up to date with any added extensions.
Replaces `ComponentIdentTypeRepr::getIdentifier()` and `getIdLoc()` with `getNameRef()` and `getNameLoc()`, which use `DeclName` and `DeclNameRef` respectively.
Pull these calls out of lookup itself to prevent re-entrancy. Synthesizing these members can force a conformance check that can ultimately wind up back in lookup. Pull the forcing out of every single qualified lookup and just install these members in the TypeChecker's entrypoints to lookup.
The upside is we can localize this gross hack, the downside is, of course, that we have to smear it across all of the lookup entrypoints.
getDirectlyInheritedNominalTypeDecls looks for inherited protocols in two places: the actual inheritance clause of a declaration and the trailing where clause. This works fine for normal declarations, but deserialized protocols that have Self constraints have no trailing where clause and appear to have no super-protocol bounds. This means clients can potentially disagree about the structure of the protocol, and any symbols derived from it.
The test case demonstrates this problem directly: We build a hollowed-out SwiftUI preview provider then try to dynamically replace a requirement in a Self-constrained protocol extension. The SwiftUI module sees the where clause, but when we go to deserialize the module in the "Preview" the protocol extension sees the wrong inheritance bounds and mis-mangles the call to Self.view(for:ofType).
The fix is to ask the requirement signature for Self requirements that would normally appear on a trailing where clause.
Resolves rdar://57150777
This allows us use an OptionSet parameter for
the request (as currently we can't directly use it
as a parameter due to not having an == definition
for it). It also allows us to regain default
arguments for the source loc and flag parameters.
