conformances
rdar://16539292
This is a hack in visible decl lookup. The general solution that would also
improve type checker errors would be to make the type checker keep these broken
conformances and syntethize missing declarations to make downstream code type
check. For that, see:
<rdar://problem/16723339> [QoI] Type checker should not be dropping protocol
conformances explicitly spelled in the source
Swift SVN r16818
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
This started out life as a helper class, but it's been used in multiple places.
Better to just have a single copy.
No functionality change.
Swift SVN r10835
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
And, properly treat imports as per-file: when looking up decls through the
TU module, don't pick up every other source file's imports.
This implements our resolution rules:
1. Check the current source file.
2. Check the current module.
3. Check imported modules.
Currently, "import Foo" is treated as a file-private import and
"@reexported import Foo" is treated as a public /and/ module-wide import.
This further suggests that access control is the right tool for re-export
control:
(private) import Foo // current file only
package import Foo // whole module
public import Foo // whole world
Swift SVN r9682
ASTContexts
This introduces swift::ide::CodeCompletionCache, which is a persistent code
completion result cache.
Right now REPL happens to use it (try importing Cocoa and doing code
completion), and the difference is noticeable. But completion in REPL is
still slow, because Cocoa goes through the AST Verifier on every completion
(for unknown reasons).
This commit does not implement cache invalidation yet, and it does not use
libcache to evict cache entries under memory pressure.
This commit also introduces two regressions:
- We get fewer Cocoa results that expected. Module::isModuleVisible in Clang
does not incorrectly reports that that ObjectiveC.NSObject submodule is not
visible from Cocoa.
- We are not implementing the decl hiding rules correctly. We used to rely on
visible decl lookup to do it for us, but now we have a different data structure
we have real decls from the current module and we have a text-only cache, so we
are forced to reimplement this part of name lookup in code completion.
Swift SVN r9633
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
There were two overloads of lookupVisibleDecls: one that performed
unqualified lookup from a particular decl context, the other performing
qualified lookup into a given type from a particular decl context.
They don't really behave the same, so let's give them different names.
Swift SVN r8641
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
Removes the boolean IsTypeLookup and OnlyInstanceMembers, which were totally
misleading.
This fixes some bugs in lookupVisibleDecls, which allows us to remove
workarounds in code completion, that were not correct in some corner cases.
Now we also code complete references to instance functions in static contexts,
but code completion results in this case state the type of the resulting object
incorrectly.
Swift SVN r6396
the containing DeclContext
Fixes a few FIXMEs in code completion where we were providing results that
refer to generic arguments outside of their scope.
Swift SVN r6370
is documented: look up members of a type that are visible from a specific
module. It does not matter much now, but when we have access control, it will.
Before this change, lookupVisibleDecls() tried to guess the *defining* module
of the type, and gave up if it could not. It forced us to duplicate some
lookup logic for some types (archetypes and protocol compositions). Also add a
test that lookup finds members of archetype's superclass, which the original
(duplicated) code did not handle.
Swift SVN r6363
By default, reject references to generic types that are not
accompanied by explicitly-provided generic arguments. For those few
places where we can infer the generic arguments (such as the element
type of a new-array expression), opt-in to allowing unbound generic
types. We expect to opt-in more callers over time, but it's better to
reject eagerly because inferring the generic arguments always requires
extra code.
Fixes <rdar://problem/14161142>.
Swift SVN r6016
The newer version is slightly more robust about detecting ambiguities
and reporting problems with generic arguments. It also makes direct
use of TypeChecker::lookupMemberType() when resolving member types and
is better situated for further improvements.
Swift SVN r5977
This lookup routine takes the place of MemberLookup for AST-level
lookups, which don't consider semantics at all and won't be able to
(for example) perform additional type checking to resolve the
lookup. No functionality change.
Swift SVN r5882
If -nsstring-is-string is enabled, lower Strings in cc(c) and cc(objc) function types to NSString, and when calling them, insert calls to StringToNSString/NSStringToString to perform the bridging conversion.
This isn't quite ready for prime-time yet, because we still need to emit the inverse bridging for ObjC method thunks, and I haven't tested the IRGen end of things yet.
Swift SVN r5355
When checking for a replPrint method, make sure it's not an instance method of a metatype; the signature ends up wrong and we emit bizarre error messages. Fixes <rdar://problem/13036012>.
Swift SVN r4204
If the completion prefix has a '.' behind it, guesstimate a context expression by lexing backward through an identifier(.identifier)* dotted path, then attempt to parse and typecheck that expression to decide on a base type in which to find completions.
Swift SVN r4063
Implement a 'lookupVisibleDecls' API similar to Clang's that replicates the UnqualifiedLookup logic for walking through a given scope looking for decls. Use it to populate the completion list in the repl.
Still to be done: Clang module lookup via Clang's lookupVisibleDecls, and context deduction from dotted path expressions.
Swift SVN r4056
While we haven't worked out the details of whether methods in
extensions can be overridden in Swift, it's something that does happen
in Objective-C, so we need to deal with it.
With this change, note that our demo application can both allocate
Objective-C objects with "new" (which John recently fixed) and also
subscript mutable arrays to both read and write.
Swift SVN r3485
results of member lookup, and eliminate all uses of
MemberLookup::createResultAST(). The AST library should not be
performing this semantic analysis.
Swift SVN r2221
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
