When the LHS is an lvalue/assignable tuple and there is no leading
sequence of binary expressions.
It's a bit hacky right now since we don't have a good way to
differentiate general pattern completions from builtin operators.
rdar://problem/23209683
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
1. Array type parsing for postfix array types Int[]. We now handle this
in the parser, but remove the AST representation of this old form. We
also stop making vague promises about the future by saying that "fixed
size arrays aren't supported... yet". Removal of this fixes a compiler
crasher too.
2. Remove the special case support for migrating @autoclosure from types
to parameters, which was Swift 1.0/1.1 syntax. The world has moved or
we don't care anymore.
3. Remove upgrade support for # arguments (nee "backtick" arguments), which
was a Swift 1.x'ism abolished in an effort to simplify method naming
rules.
NFC on valid code.
All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
Go beyond the existing keyword completions to include more literal
suggestions: 0, 0.0, "text", [item], [key: value], (item, item)
For rdar://problem/21923069
Swift SVN r32890
Peek at the token following the code completion location to decide
whether or not to provide completions for entire call patterns. When
the next token looks like it's part of an existing call we don't show
the patterns because they will "push out" the existing arguments.
We should now get:
Foo<here> => (blah, blah)
Foo(<here> => ['(']blah, blah)
Foo(<here>) => ['(']blah, blah[')']
Foo(<here>, blah) => just complete the values for arg1**
Foo(<here>blah, blah) => just complete the values for arg1
** A further improvement will be to add the argument label completion
for the first argument (if applicable) when we aren't showing a full
call pattern.
rdar://problem/22804670
Swift SVN r32765
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
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
When completing at the sequence position of for each statment (for i in <HRER> {}),
values of sequence type should have higher priority than the rest.
Swift SVN r32202
- Fix a diagnostic to not include redundant ''s around a type name.
- Rework CleanupIllFormedExpression to be simpler and to not
unconditionally destroy data when it doesn't. This makes a code
completion test a bit more precise.
- Completely revamp getTypeOfIndependentSubExpression, to return the
subexpression produced by type checking instead of just a type. This
is important for cases when type checking changes the root of the AST
(e.g. resolving an unresolved_dot_expr) and allows us to eliminate
grungy and unsafe recovery code that was in place to work around this.
The last point makes the examples in Constraints/lvalues.swift better (giving
a somewhat generic error instead of an specific-but-incorrect error that 'z'
is immutable), but more importantly, it fixes a class of crashers like
<rdar://problem/21369926> Malformed Swift Enums crash playground service
where we'd end up with a LiteralExpr typed as Int instead of a Builtin integer
type of some sort.
Swift SVN r29932
First, fix a case of type checking an expression twice, which is against
the design of the type checker. We hit this because we can type check
the "context" in
let x = foo.#^COMPLETE^#
and then type check the "parsed expression", which is contained in the
context here.
Second, make the hack from rdar://20738314 more robust so that if we
*do* double typecheck for some reason we won't just choke on an
AutoClosureExpr. I filed rdar://21466394 to audit for other cases of
double typechecking and remove this hack.
Fixes rdar://21346928
Swift SVN r29527
Completions for calling functions will now show 'throws' in the
description text so that users can differentiate throwing and
non-throwing calls. We don't insert this into the source text, since
it's not part of the call syntax.
rdar://problem/20978869
Swift SVN r28791
protocol P { typealias T; func foo() -> T }
func invalid(x: P) { x.#^COMPLETE^#
We were trying to access a null Type created because the associated type
doesn't make sense in the protocol type P (we can only use P as a
generic constraint, but it shouldn't crash code completion if we use it
incorrectly).
For rdar://problem/20305938
Swift SVN r28588
We were asserting (and doing the wrong thing) when trying to code
complete
nil #^HERE^#
The issue is that we tried to apply a solution to the expression that
contained free type variables (converted to generic parameters). This
trips us up when we expect the new type to conform to protocols. In code
completion we generally only need the type of the expression, so this
commit switches to getting that more explicitly. That said, this did
cause us to drop non-API parameter names in call patterns after an
opening '(' in some cases (covered by rdar://20962472).
Thanks to Doug for suggesting this solution!
rdar://problem/20891867
Swift SVN r28584
After this change,
extension P where WHERE1 { final func foo() {} }
extension P where WHERE2 { final func bar() { #^COMPLETE_HERE^#
will complete foo() if and only if WHERE2 is complatible with WHERE1.
Swift SVN r27480
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
We want to complete foo(p: (Int, Int)) as foo({#(p): (Int, Int)#}), not
as foo({#Int#}, {#Int#}). Also, make initializers go through the
function parameter code path rather than the enum one, since we don't
want to recursively find parameters in tuples.
<rdar://problem/17461862>
Swift SVN r19514
instead, so it picks up substituted types. BodyParamPatterns is now only
used for the local non-api parameter name.
Consolidate the two variations of addFunctionCallPattern() into one function.
Update the tests accordingly.
This addresses <rdar://problem/16956363>.
Swift SVN r18481
if there's no parameter API name. This is for display purposes only.
Update all relevant tests accordingly.
This addresses <rdar://problem/16768768>.
For example:
class X {
func f(a: Int, b: Int) { }
}
Would previously display like this in code completion in Xcode:
f(<#Int#>, b: <#Int#>)
The local parameter name, while not API, often still conveys meaning
to the user. So it's now included like this:
f(<#a: Int#>, b: <#Int#>)
Swift SVN r18403
The leading paren is included for display purposes only, not inserted
in the code if already present. It makes the displayed text in the
code completion list symmetrical with respect to open/close parens.
Add markups when printing annotation chunks so it becomes testable.
Update tests accordingly, and include tests for leading parens.
This addresses <rdar://problem/16918310>.
Swift SVN r18126
