Similar to 4cf7426698 but for the case
when the completion is in a default argument expression rather than
initializer. Fixed to grab either the initializer or default argument if
there is one.
Strings are a single token, so the previous check would treat
completions inside string interpolations as being outside of the
initializer.
Grab the end of the token from the Lexer, but wrap in a context check to
avoid performing that for every declaration found in the lookup.
Resolves rdar://70833348
`::lookupVisibleDecls` had an inline consumer in order to remove
"unusable" results. Refactor this method, moving the consumer (now
`UsableFilteringDeclConsumer`) to allow its use when looking up top
level module declarations.
Also use the `AccessFilteringDeclConsumer` in preference to a condition
in `addVarDecl`.
Resolves rdar://56755598
This attribute allows to define a pre-specialized entry point of a
generic function in a library.
The following definition provides a pre-specialized entry point for
`genericFunc(_:)` for the parameter type `Int` that clients of the
library can call.
```
@_specialize(exported: true, where T == Int)
public func genericFunc<T>(_ t: T) { ... }
```
Pre-specializations of internal `@inlinable` functions are allowed.
```
@usableFromInline
internal struct GenericThing<T> {
@_specialize(exported: true, where T == Int)
@inlinable
internal func genericMethod(_ t: T) {
}
}
```
There is syntax to pre-specialize a method from a different module.
```
import ModuleDefiningGenericFunc
@_specialize(exported: true, target: genericFunc(_:), where T == Double)
func prespecialize_genericFunc(_ t: T) { fatalError("dont call") }
```
Specially marked extensions allow for pre-specialization of internal
methods accross module boundries (respecting `@inlinable` and
`@usableFromInline`).
```
import ModuleDefiningGenericThing
public struct Something {}
@_specializeExtension
extension GenericThing {
@_specialize(exported: true, target: genericMethod(_:), where T == Something)
func prespecialize_genericMethod(_ t: T) { fatalError("dont call") }
}
```
rdar://64993425
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
Rather than relying on clients to cope with the potential for circular
inheritance of superclass declarations, teach SuperclassDeclRequest to
establish whether circular inheritance has occurred and produce "null"
in such cases. This allows other clients to avoid having to think about
To benefit from this, have SuperclassTypeRequest evaluate
SuperclassDeclRequest first and, if null, produce a Type(). This
ensures that we don't get into an inconsistent situation where there
is a superclass type but no superclass declaration.
Private imports are intended to make the file performing the import more or less source-compatible with the file being imported from, so that code from the original file can be modified by relatively simple syntactic transformations. However, their name shadowing behavior was very different from the original file. In the original file, other declarations in the same module would have shadowed declarations imported from any other module; in a file using a @_private import, they would all be considered imports, and thus all would be preferred equally. This could cause ambiguity in a file using a @_private import that was not present in the original file.
This commit changes that behavior by favoring @_private imports over other imports, so that if a name is visible through both a private and a non-private import, the one visible through the private import will shadow the other. This shadowing takes a higher priority than a scoped import, but a lower priority than the check for whether one of the modules is only visible through the other.
Fixes rdar://68312053.
UnqualifiedLookupRequest takes a DeclContext and a SourceLoc. If the
SourceLoc is valid, it locates the innermost ASTScope containing this
location, and starts the lookup from that scope.
Also, ASTScope currently walks up the scope tree to find the
innermost scope that corresponds to the given DeclContext, in case
the DeclContext is a parent of the 'natural' DeclContext for this
source location.
We want to remove this additional behavior and make ASTScope only
depend on a source file and source location.
This requires changing directReferencesForUnqualifiedTypeLookup()
to handle the top-level lookup case explicitly. See the comment for
more details.
TypeChecker::lookupMemberType() performs a lookup on the base type,
and disambiguates multiple results by filtering out result decls
that have canonically equal types under the base type substitution.
I'd like to refactor conformance checking to call lookupQualified()
directly and bypass lookupMemberType(), but this requires adding a
new shadowing rule to primitive name lookup to simulate the effect
of the type-based disambiguation.
We already had a shadowing rule which states that concrete type
members shadow protocol members of the same name, but this was
bypassed for member _types_. This change generalizes this rule to
apply to member types also.
Hopefully this doesn't break source compatibility in practice.
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
