experimental code-completion path. Move them right before "other module"
results. This is a bit of a hack. Ideally, we would have a much better
idea which keywords are actually legal/likely in a given context and
could prioritize them even more. Since today we basically splat in all
the keywords, keep them below the current module results so they don't
overwhelm us.
rdar://problem/25119529
... in the experimental code-completion path. They seem to be generally
useful as a baseline result still as long as they are guaranteed to be
the first result.
rdar://problem/25177968
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
In the experimental operator completion, we were mysteriously missing
some operators like ||. It turns out it was all operators
alphabetically after '.', because the filtering code was very broken.
rdar://problem/23539465
We won't try to avoid the stdlib completely, but at least try not to
check method names on types that might change in the future.
For rdar://problem/24621131
Experiment with having some locals or nominal members come first, but
only a few so that the literals are still predictably near the top.
Part of rdar://problem/23865118
If there is a type context, hide literal suggesetions that don't match
it, unless they are keywords and we have filtered to their names.
Incidentally fix an output buffering issue when combining filtering with
the -raw flag in complete-test.
Part of rdar://problem/23865118
In practice things that are float literal convertible are also integer
literal convertible so this isn't pulling its weight.
Part of rdar://problem/23865118
On a per-request basis. Allows hiding/showing at multiple granularities
* everything
* module
* API by name
* keywords (by uid or all of them)
* literals (by uid or all of them)
With more specific rules overriding less specific ones (so you can hide
everything and then selectively show certain API for example).
rdar://24170060
This makes it more clear what the response string contains, plus you can copy the
printed request directly for passing to sourcekitd_request_create_from_yaml.
The internal parameter names are just there to give an extra hint in the
source text for what the argument is. Consequently, we don't want to
allow filtering to match against them.
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
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
Ben Langmuir
Saleem Abdulrasool
Max Moiseev
Daniel Duan
Dmitri Gribenko
Nate Cook
Chris Lattner
David Farler
Argyrios Kyrtzidis
Doug Gregor
Erik Eckstein
gregomni
practicalswift
ken0nek
Xi Ge
Jordan Rose