* [InterfaceGen] Remove #ifs from default args
This patch removes all #if configs form the bodies of default arguments,
which can contain multiline closures, while preserving the bodies of the
clauses that are active.
This code is generalized and should "just work" for inlinable function
bodies, which will come in a later patch.
* Address review comments
* Fix and test CharSourceRange.overlaps
* Fix CharSourceRange::print to respect half-open ranges
CompletionLookup::IsStaticMetatype was not explicitly initialized during construction, so it could sometimes have garbage values. This caused UBSan to error out on IDE/complete_enum_elements.swift and IDE/complete_unresolved_members.swift.
The right way is findBufferContainingLoc. getBufferIdentifierForLoc is
both slower and wrong in the presence of #sourceLocation.
I couldn't come up with a test for the change in IDE/Utils.cpp because
refactoring still seems to be broken around #sourceLocation. I'll file
bugs for that.
This is not any "better" because we also want to eventually
remove decomposeInput() too. However we're planning on
scrapping TypeReconstruction altogether so its unlikely that
refactoring this to do the right thing will be worth it.
Instead just inline what getOld() does so we can move forward.
Before this patch, we used to define tooling-specific diagnostics. With adding more
checking logics, we found this mechanism hard to extend. This patch
eliminates the home-made diagnostics model to use the one from compiler, which provides
several benefits: less boiler-templates, better integration with DiagnosticConsumer,
and easy ordering of detected issues.
* Handle completion in 'parseExprKeyPath()' instead of
'parseExprPostfixSuffix()'.
* Fix a crash for implicit type keypath. e.g. '\.path.<complete>'. (SR-8042).
* Use 'completeExprKeyPath()' callback.
* Implement completion without '.'. e.g. '\Ty.path<complete>'
* Improved handling for 'subscript' in completion.
* Improved handling for optional unwrapping in completion.
https://bugs.swift.org/browse/SR-8042
rdar://problem/41262612
* Consolidate CompletionKind::KeyPathExpr and CompletionKind::KeyPathExprDot
to CompletionKind::KeyPathExprObjC
* Make completeKeyPath() to receive DotLoc.
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Unresolved type attached to expressions may fail re-typechecking.
Also, disallow unresolved type in typeCheckCompletionSequence(). It doesn't
provide useful completions to developers.
rdar://problem/41224316
A significant chunk of the handling for LookupKind::ValueExpr
was duplicated in the handling for the ValueInDeclContext and
ImportFromModule cases. Use a fall through to unify the
code paths here.
That is, don't look through InOutType anymore, and update callers to
call getInOutObjectType() as well (or not, where it was obvious to me
that InOutType could not appear).
This surfaces more remaining uses of getInOutObjectType() directly.
Explict cast expressions (i.e. 'as', 'as!`, 'as?', and 'is') appear twice in
'SequenceExpr'. For instance, 'a as B' is parsed as:
(sequence_expr
(unresolved_declref_expr name='a')
(coerce_expr writtenType='B')
(coerce_expr writtenType='B'))
This patch prevents ModelASTWalker from walking into them twice.
rdar://problem/43135727
Using dummy UnresolvedMemberExpr doesn't give us much benefit. Instead, use
CodeCompletionExpr which is type checked as type variable so can use
CodeCompletionTypeContextAnalyzer to infer context types.
This way, we can eliminate most of special logic for UnresolvedMember.
rdar://problem/39098974
* Don't need to look for CodeCompletionExpr. It's wrong anyway because
what we are looking for is not neccessarily a 'CodeCompletionExpr'.
* Use getElementLoc(i).isValid() instead of !getElementName(i).empty().
Just in case users write '_:' for call argument.
* Don't suggest argument labels for implicit call expression. For
instance, string interpolation segments.
* For methods, un-curry function interface type so we can get declared
return type.
* For closures, fall back to getting explicit result type in case we
cannot retrieve it from the type of closure itself.
