Previously, property names are hidden in the whole range of the
declarations. Now, it's only hidden in its own initializer range.
rdar://problem/49697202
This adds an implicit body so that we can dig out the return type
context the same way as a normal function. For now, we are also treating
the first expression in a multi-statement implicit getter body the same
way; we'll need to refactor how we complete in accessors to
differentiate those cases.
There were 2 functions to output argument list. Consolidate them and
consistently use it from every call like production (i.e. function call,
constructor call, enum with associated values, subscript)
Instead of re-typechecking parsed expression, find typechecked
expression that corresponds to the parsed expression from the
typechecked decl context, because the sub expressions of the parsed
expression can be weirdly mutated/replaced by decl context typechecking.
rdar://problem/48141174
The logic here had diverged from UnqualifiedLookup. One day we'll merge
the two, for now clean it up a bit to match.
Note that all generic parameters now have 'Reason' reported as 'Local'.
I don't believe this really matters.
Fixes <rdar://problem/20530021>.
Add null type check for `Self` type in `UnqualifiedLookup`. It seems this
doesn't happen in normal compilation. But when code-completion happens in
inactive conditional compilation block, since surrounding context hasn't
been typechecked, `Self` type can be null.
rdar://problem/41234606
Other instances of fb9c65e. Consistently use
PrintOption.PrintOptionalAsImplicitlyUnwrapped to print IUO.
rdar://problem/41046225
rdar://problem/42443512
Follow-up to f577578a6a. The same
treatment for ternary expression (IfExpr). Plus, fix a regression
introduced in f577578a where infix operators were disappeard from
results.
foldSequence() may hoist these expression up by mutating their sub
expression. When completing operators, this behavior ruins reusability
of operand. Since these expression doesn't affect completion, we can
strip them out.
rdar://problem/42452085
In getOperatorCompletions(), for each every known operators, temporary
expressions are created and typechecked. In this process, typechecker
may set the type of the parsed expression. That may cause non-accurate
completion results or crash at worst.
rdar://problem/28188259
Validation of the input side of FunctionTypeRepr was previously being done in Sema because of expression folding. If we instead push the invariant that the input TypeRepr should always be a TupleTypeRepr into the AST a number of nice cleanups fall out:
- The SIL Parser no longer accepts Swift 2-style type declarations
- Parse is more cleanly able to reject invalid FunctionTypeReprs
- Clients of the AST can be assured the input type is always a TupleType so we can flush Swift 2 hacks
Before checking any requirements of the binding type, let's look
through @autoclosure and/or non-variable types if source constraint
requires that, otherwise we'd end up creating bindings for types
which later on might end up causing infinite recursion like dependent
member types in result position of @autoclosure parameter.
Resolves: rdar://problem/38272904
They can show up when re-typechecking via diag or code-completion and were
only being sanitized out in one place in CSDiag. Moved that logic into
SanitizeExpr.
Resolves rdar://problem/38149042
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
Constructor call patterns already get a real priority, but because of
the way we do function call patterns we don't have enough information,
and previously we were setting it to "expression specific", which is
unnecessarily high, particularly since functions (unlike inits) have
other better ways to code-complete already.
rdar://31113161
When completing
Foo(<here>
We will now provide
bar: <#value#>
instead of
bar: <#value#>)
Inserting the rparen caused some problems in practice:
* the old behaviour optimized for typing Foo(<complete> instead of
Foo(<complete>), which can conflict with user behaviours or ...
* in editors with automatic brace-matching, we often conflicted with the
editor, leading to extraneous closing parens
And in general, it is much more predictable for tooling to either insert
matching ( and ) or to not insert either. While this change may not be
ideal For users of editors that do not do automatic brace-matching, I
believe it is still better overall to have to type a missing paren than
to have to delete an extraneous one.
rdar://31113161
Even if we don't apply the solution, we still end up writing
types into ParamDecls of closures contained the expression.
Make sure this is idempotent by disabling 'cleanup', which
avoids setting them to ErrorTypes, and teaching ExprCleaner
to clear out types of VarDecls.
This is a hack that will get better once the constraint
system type map stuff is further along.
Fixes <rdar://problem/33219081>.
This doesn't give particularly useful information yet (i.e. Self isn't
listed, see rdar://problem/31981641 ), but it does stop the completion
code from just directly crashing.
Fixes rdar://problem/31981486.
[CodeCompletion] Using the default constraints generator for TupleExpr
when inferring the type of unresolved members. rdar://28991372
When code completing, we used to create a type variable to represent the type
of an entire tuple expression. However, recent improvements on parser make this
step unnecessary and crash-prone. Thus, we use the default constraint
generator to interpret tuple expressions.
This fixes several issues:
- By default parent types of alias types are not printed which results in
- Erroneous fixits, for example when casting to 'Notification.Name' from a string, which ends up adding erroneous cast
as "Name(rawValue: ...)"
- Hard to understand types in code-completion results and diagnostics
- When printing with 'fully-qualified' option typealias types are printed erroneously like this "<PARENT>.Type.<TYPEALIAS>"
The change make typealias printing same as nominal types and addresses the above.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This allows us to start code-completing infix operators in postfix
expressions. As a first step, this patch only handles completing
against the immediate LHS (so for example 1 == 1 <here> doesn't suggest
boolean operators yet).
The next step is to feed the leading sequence expression from the parser
in so we can consider how the operator being completed fits into the
whole sequence expression.
For rdar://problem/22460167
Swift SVN r32465
For now, just avoid adding the completion since that will assert later
when we try to sort. In the future we could actually complete something
useful here, since we can dig out the names of the parameters even if
the type is invalid.
rdar://problem/22834017
Swift SVN r32211
Salvaging can try to apply a solution when producing diagnostics, and we
can't generally apply solutions in code completion because they may
contain free type variables.
rdar://problem/22836263
Swift SVN r32203
