This centralizes some invariants around the 'self' parameter.
While all ConstructorDecls and DestructorDecls have a 'self',
even if they're invalid because they're not nested inside a type,
we don't want to consider this as the base 'self' for lookups.
Eg, consider this invalid code:
class C {
func f() {
init() {
x
}
}
}
The base for the lookup should be f.self, not f.init.self.
Let's use a ClosureParametersScope for all closures, even those
without an 'in' keyword. This eliminates the need for the
ClosureBodyScope and WholeClosureScope.
Also, let's move the lookup of capture list bindings from
CaptureParametersScope to CaptureListScope. This eliminates the
need for CaptureParametersScope to store a reference to the
capture list, which allows us to remove the AbstractClosureScope
base class entirely.
In a code snippet like the following,
static func ==(a: Foo, b: Foo) -> Bool {
switch (a, b) {
case (.x(let aa), .x(let bb)) where condition(aa, bb),
(.y(let aa), .y(let bb)) where condition(aa, bb):
return aa == bb
default:
return false
}
}
The CaseStmt defines two patterns, both of which bind
'aa' and 'bb'. The first 'aa'/'bb' are in scope inside the
first 'where' clause, and the second 'aa'/'bb' are in scope
inside the second 'where' clause.
Furthermore, the parser creates a "fake" VarDecl for
'aa' and 'bb' to represent the phi node merging the two
values along the two control flow paths; these are in scope
inside the body.
Model this situation by introducing a new CaseLabelItemScope
for the 'where' clauses, and a CaseStmtBodyScope for the
body.
The function builder transform creates pattern bindings parented
in other DeclContexts. If those pattern binding initializer
expressions in turn contain multi-statement closures, we will
try to perform unqualified lookups from those contexts when we
get around to type checking the closure body.
Change some unconditional casts to conditional casts in ASTScope
lookup, to handle this case. The casts are only performed while
checking if the initializer context is part of a 'lazy'
property, which doesn't apply here.
Fixes <rdar://problem/67265731>.
The comparision happens only by 'comp(element, value)' not
'comp(value, element)'. We only need
`operator()(const ASTScopeImpl *, SourceLoc)`.
Use llvm::lower_bound() instead of std::lower_bound().
* Re-create `ASTScope` for each completion
* Add generic params and where clause scope even without missing body
* Use `getOriginalBodySourceRange()` for `AbstractFunctionBodyScope`
* Source range translations for replaced ranges when finding scopes
* Bypass source range checks when the completion happens in the replaced
range
* Be lenient with ASTScope / DeclContext mismatch in code completion
Rather than depending on the tracking of state in switch cases to
remember the case statements that are the source and destination for a
`fallthrough` statement, compute them using ASTScope to find the
nearest enclosing case (the source) and then find the next case in the
same `switch` statement (the destination).
`guard` statements are prohibited from having labels, and aren't
actually break/continue targets. Stop producing them as results from
ASTScope-based labeled statement lookup and don't add them as a
labeled statement in the recursive walk.
Use the scope map to implement lookup for the labeled statements that
are visible from a given source location, which is a lexical property
that is currently handled with stateful tracking in the type checker.
For now, merely assert that the results of this approach are identical
to the state tracked in the statement type checker.
Today, ASTScope only creates NominalTypeWhereScopes for the 'where'
clause of an extension or a protocol. All other generic declarations
model the 'where' clause as part of the declaration's scope itself
(but it's not part of the body scope).
Lookups into the NominalTypeWhereScope would look inside the type,
because this is how we want protocol and protocol extension scopes
to work -- you should be able to refer to associated types without
a 'Self' prefix.
Let's add a conditional check for protocols and extensions to the
implementation of NominalTypeWhereScope, so that we can use this
scope for all other 'where' clauses and keep the old behavior.
Note that today, even _concrete_ extensions have this behavior,
which is perhaps slightly unexpected:
class C<T> {
typealias U = Int
}
extension C where T == U {}
It would be nice to tighten up the rule here but there's already a
test in the suite that depends on it.
Add a new GenericContext::getParsedGenericParams(). This produces
the same value as GenericContext::getGenericParams() if the generic
parameter list was written in source. For extensions and protocols,
this returns nullptr without synthesizing anything.
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
`@differentiable` attributes may contain `where` clauses referencing generic
parameters from some generic context, just like `@_specialize` attributes.
Without special ASTScope support for `@differentiable` attributes,
ASTScopeLookup.cpp logic tries to resolve the generic parameter `DeclName`s in
`where` clauses based on source location alone
(`ASTScopeImpl::findChildContaining`) and fails.
The fix is to add a special `DifferentiableAttributeScope`, mimicking
`SpecializeAttributeScope`. Every `@differentiable` attribute has its own scope,
derived from the declaration on which it is declared. Unlike `@_specialize`,
`@differentiable` may also be declared on `AbstractStorageDecl` declarations
(subscripts and variables).
Upstreams https://github.com/apple/swift/pull/27451.
Progress towards TF-828: upstream `@differentiable` attribute type-checking.
* 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
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.
Switch most callers to explicit indices. The exceptions lie in things that needs to manipulate the parsed output directly including the Parser and components of the ASTScope. These are included as friend class exceptions.
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.
