This commit adds a new ValueDecl::isLocalCapture() predicate and
uses it in the right places. The predicate is true if the
declaration is in local context, *or* if its at the top level of
the main source file and follows a 'guard' statement.
Fixes <rdar://problem/23051362> / <https://bugs.swift.org/browse/SR-3528>.
* 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.
- Introduce ide::CompletionInstance to manage CompilerInstance
- `CompletionInstance` vends the cached CompilerInstance when:
-- The compiler arguments (i.e. CompilerInvocation) has has not changed
-- The primary file is the same
-- The completion happens inside function bodies in both previous and
current completion
-- The interface hash of the primary file has not changed
- Otherwise, it vends a fresh CompilerInstance and cache it for the next
completion
rdar://problem/20787086
When Protocol P and Struct S are in a same module and S conforms to P, the protocol
witness table is emitted directly as a symbol. If we move P to a lower-level module,
the protocol witness table symbol isn't emitted, breaking users' existing executable as
a result.
This change checks whether the protocol used to be defined in the same
module and marks it as non-resilient if so. The compiler will continue
emitting witness table as symbols to maintain cross-module ABI stability.
Replaces `ComponentIdentTypeRepr::getIdentifier()` and `getIdLoc()` with `getNameRef()` and `getNameLoc()`, which use `DeclName` and `DeclNameRef` respectively.
We had two predicates that were used to determine whether the default
argument for a wrapped property in the memberwise initializer would be
of the wrapper type (e.g., Lazy<Int>) vs. the wrapped type
(Int). Those two predicates could disagree, causing a SILGen assertion
and crash. Collapse the two predicates into one correct one,
fixing rdar://problem/57545381.
Complete the refactoring by splitting the semantic callers for the original decl of a dynamically replaced declaration.
There's also a change to the way this attribute is validated and placed. The old model visited the attribute on any functions and variable declarations it encountered in the primary. Once there, it would strip the attribute off of variables and attach the corresponding attribute to each parsed accessor, then perform some additional ObjC-related validation.
The new approach instead leaves the attribute alone. The request exists specifically to perform the lookups and type matching required to find replaced decls, and the attribute visitor no longer needs to worry about revisiting decls it has just grafted attributes onto. This also means that a bunch of parts of IRGen and SILGen that needed to fan out to the accessors to ask for the @_dynamicReplacement attribute to undo the work the type checker had done can just look at the storage itself. Further, syntactic requests for the attribute will now consistently succeed, where before they would fail dependending on whether or not the type checker had run - which was generally not an issue by the time we hit SIL.
Add DynamicallyReplacedDeclRequest to ValueDecl and plumb the request through to TypeCheckAttr where it replaces TypeChecker::findReplacedDynamicFunction.
This is a first version of cross module optimization (CMO).
The basic idea for CMO is to use the existing library evolution compiler features, but in an automated way. A new SIL module pass "annotates" functions and types with @inlinable and @usableFromInline. This results in functions being serialized into the swiftmodule file and thus available for optimizations in client modules.
The annotation is done with a worklist-algorithm, starting from public functions and continuing with entities which are used from already selected functions. A heuristic performs a preselection on which functions to consider - currently just generic functions are selected.
The serializer then writes annotated functions (including function bodies) into the swiftmodule file of the compiled module. Client modules are able to de-serialize such functions from their imported modules and use them for optimiations, like generic specialization.
The optimization is gated by a new compiler option -cross-module-optimization (also available in the swift driver).
By default this option is off. Without turning the option on, this change is (almost) a NFC.
rdar://problem/22591518
The computation for "is explicitly initialized" on a pattern binding
entry didn't account for explicit initialization via the property
wrapper (e.g. @Wrapper(closure: { ... })), which lead to a crash for
properties with optional type. Fixes rdar://problem/57411331.
When an original module name is specified via @_originalDefinedIn attribute, we need to
use the original module name for all related runtime symbol names instead of the current
module names.
rdar://55268186
This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
This commit introduces a request to type-check a
default argument expression and splits
`getDefaultValue` into 2 accessors:
- `getStructuralDefaultExpr` which retrieves the
potentially un-type-checked default argument
expression.
- `getTypeCheckedDefaultExpr` which retrieves a
fully type-checked default argument expression.
In addition, this commit adds `hasDefaultExpr`,
which allows checking for a default expr without
kicking off a request.
This commit adds a request that computes
the initializer context for a parameter with a
default expr or stored property default.
This avoids having to compute them for synthesized
decls and is a step towards requestifying default
argument parsing.
When SE-110 was being implemented, we accidentally began to accept
closure parameter declarations that had no associated parameter names,
e.g.
foo { ([Int]) in /**/ }
This syntax has never been sanctioned by any version of Swift and should
be banned. However, the change was made long enough ago and there are
enough clients relying on this, that we cannot accept the source break
at the moment. For now, add a bit to ParamDecl that marks a parameter
as destructured, and back out setting the invalid bit on the type repr
for these kinds of declarations.
To prevent further spread of this syntax, stub in a warning that offers
to insert an anonymous parameter.
Resolves part of rdar://56673657 and improves QoI for errors like
rdar://56911630
If a property has multiple property wrappers attached, we'll have multiple nested calls, where each call's argument is a call to construct the next wrapper in the chain. However, when we use multiple wrappers consecutively, we cannot just rely on the call's type matching the innermost wrapper's type, because it will match the first wrapper in the sequence of consective wrappers and we'll end up crashing in SILGen. So, we should check if the call's argument is another call and look into that before checking the types.
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
Now that isInvalid() is a semantic property, drop the assertion for this
invariant in the ASTVerifier. This should also remove the last client
that wasn't registering the lazy resolver and expecting to pull any old
interface type out, so change a hack to an assertion to hopefully catch
future callers before we remove the LazyResolver entirely.
