When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Accept `getInterfaceType->hasError()` declarations. Even if the part of
the declaration has error, we still have chance to get context info from
the other part of it. For instance:
func foo(x: Int, y: INt) { }
foo(x: #^COMPLETE^#
We should resolve 'Int' as the context type even if parameter `y` is an
error type.
In `<expr> '(' <code-completion-token>` case, we usually complete call
arguments. If '<expr>' isn't typechecked, for example, because of
overloading, we used to give up arguments completions.
Now, use possible callee informations from the context type analyzer. This
increases the chance to provide accurate completions.
rdar://problem/43703157
In postfix completion, for operator completion, we do:
1. Type check the operand without applying it, but set the resolved
type to the root of the expression.
2. For each possible operators:
i. Build temporary binary/postfix expression
ii. Perform type checking to see whether the operator is applicable
This could be very slow especially if the operand is complex.
* Introduce `ReusePrecheckedType` option to constraint system. With
this option, CSGen respects pre-stored types in expressions and doesn't
take its sub-expressions into account.
* Improve type checking performance because type variables aren't
generated for sub-expressions of LHS (45511835)
* Guarantee that the operand is not modified by the type checker because
expression walkers in `CSGen` doesn't walk into the operand.
* Introduce `TypeChecker::findLHS()` to find LHS for a infix operator from
pre-folded expression. We used to `foldSequence()` temporary
`SequenceExpr` and find 'CodeCompletionExpr' for each attempt.
* No need to flatten folded expression after initial type-checking.
* Save memory of temporary `BinaryExpr` which used to be allocated by
`foldSequence()`.
* Improve accuracy of the completion. `foldSequence()` recovers invalid
combination of operators by `left` associative manner (with
diagnostics). This used to cause false-positive results. For instance,
`a == b <HERE>` used to suggest `==` operator. `findLHS()` returns
`nullptr` for such invalid combination.
rdar://problem/45511835
https://bugs.swift.org/browse/SR-9061
Also, stop context type analysis at outer most expression that matches
the position. It seems that that produces more appropriate results.
rdar://problem/30103287
For:
class MyClass {
func foo(x: SomeType)
func foo(x: OtherType)
}
func test(obj: MyClass) {
obj.foo(x: <HERE>)
}
Type checker doesn't keep overloaded choices for 'obj.foo' in the AST
after typechecking. Code completion need to lookup members to collect
possible parameter types.
in unresolved member completion. e.g.
struct Node {
typealias Child = Node
init(children: [Child]) {}
}
let node: Node = .#^COMPLETE^#
This used to emit `.init(children:)` and `.Child(children:)`.
Implement 'get', 'set', 'willSet', 'didSet' completion at the beginning
of accessor position.
var value: Ty {
<HERE> // 'get', 'set', 'willSet' and 'didSet' along with normal
// completion.
}
var value: Ty {
get { return ... }
<HERE> // 'get', 'set', 'willSet' and 'didSet' only.
}
rdar://problem/20957182
It is possible for the SIL optimizers, IRGen, etc. to request information
from the AST that only the type checker can provide, but the type checker
is typically torn down after the “type checking” phase. This can lead to
various crashes late in the compilation cycle.
Keep the type checker instance around as long as the ASTContext is alive
or until someone asks for it to be destroyed.
Fixes SR-285 / rdar://problem/23677338.
(and TupleExpr at non-call argument position).
Now, unresolved member completion in array literal should work.
Also, Don't calculate convertibility to 'Any' type. That would be a
noise to type relation because anything is convertible to 'Any'.
rdar://problem/43302814
Previously, local decls in trailing closure didn't show up if the
closure had preceding arguments and the completion was triggered at
beginning position of expression context. like:
funcName(x: arg1) {
var localVar = 12
if <HERE>
}
The completion mode used to be overwritten in 'completeCallArg()' which
is called from 'parseExprCallSuffix(). We should detect completion for
immediate argument position in 'parseExprList()'.
rdar://problem/41869885
Added the 'Module::getPrecedenceGroups' API to separate precedence group lookup
from 'Module::lookupVisibleDecls', which together with 'FileUnit::lookupVisibleDecls',
to which the former is forwarded, are expected to look up only 'ValueDecl'. In particular, this
prevents completions like Module.PrecedenceGroup.
Before checking type relation between candidate types and expected
types. In normal compilation, this removal is done in CSGen. However,
since code-completion directly uses Constraint System, we have to
manually remove argument labels before checking convertibility.
We can remove argument labels unconditionally because function types as
as value cannot have argument labels. (i.e. `let f: (a: Int) -> Int` is
illegal). That means, expected types shouldn't have any argument labels.
This fixes regression revealed in 5e75b1ad3b
rdar://problem/41496748
* Handle generic base types
* Suggest '.some' and '.none' for optional types
* Don't look through too many parameter lists for function types
* Include members with convertible type result
rdar://problem/44803439
We need to look through the optional and find the members of T when
doing completion in Optional<T>.
let x: Foo? = .foo
We still don't correctly complete .some/.none, which requires
reconciling the unbound generic type we get from the decl with the real
bound generic type.
rdar://44767478
* [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.
