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.
Codable's deep magic currently forces conformance checks in the middle
of name lookup in order to inject CodingKeys into lookup results. This
is compounded by the fact that this lookup fixup is occuring
incrementally, meaning depending on order of requirements being looked
up, Decl::getMembers() will give you a different answer.
Compounding this, NameLookup relied on the LazyResolver to formalize
this layering violation, and relied on implicit laziness to guard
against re-entrancy.
The approach is multi-pronged:
1) Shift the layering violation into the request evaluator
2) Spell out the kinds of resolution we support explicitly (make them
easier to find and kill)
3) Remove the LazyResolver entrypoint this was relying on
4) Split off the property wrappers part into its own utility
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
Patch up all the places that are making a syntactic judgement about the
isInvalid() bit in a ValueDecl. They may continue to use that query,
but most guard themselves on whether the interface type has been set.
Swift 5.1's lookup for custom attributes skipped associated type
members, which allowed code like the given example to compile. To
maintain source compatibility, identify the narrow case that happens
in practice---the property wrapper is at module scope but is now
shadowed by an associated type---warn about it, and accept it.
Fixes rdar://problem/56213175.
Remove the early return in the case where one of our parent contexts was
being validated, and replace it with a simpler check that is only
performed in some callers related to associated type inference; we want
to bail out in one specific case only, which is that the declaration
is inside an extension whose generic signature is in the process of
being computed.
The existing rules sometimes behaved this way, because validateDecl()
bails out silently without error on circularity.
Let's make this explicit instead, and get it working in all cases.
Fixes <rdar://https://bugs.swift.org/browse/SR-3492> and
<rdar://problem/45889192>.
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
Computing the interface type of a typealias used to push validation forward and recompute the interface type on the fly. This was fragile and inconsistent with the way interface types are computed in the rest of the decls. Separate these two notions, and plumb through explicit interface type computations with the same "computeType" idiom. This will better allow us to identify the places where we have to force an interface type computation.
Also remove access to the underlying type loc. It's now just a cache location the underlying type request will use. Push a type repr accessor to the places that need it, and push the underlying type accessor for everywhere else. Getting the structural type is still preferred for pre-validated computations.
This required the resetting of a number of places where we were - in many cases tacitly - asking the question "does the interface type exist". This enables the removal of validateDeclForNameLookup
