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
