This is our first statement attribute, made more complicated by the
fact that a 'case'/'default' isn't really a normal statement. I've
chosen /not/ to implement a general statement attribute logic like we
have for types and decls at this time, but I did get the compiler
parsing arbitrary attributes before 'case' and 'default'. As a bonus,
we now treat all cases within functions as being switch-like rather
than enum-like, which is better for recovery when not in a switch.
Adds a -working-directory option which can be used to modify how
relative paths are resolved. It affects all other paths used in driver
options (controlled by a new ArgumentIsPath flag on options) as well as
the contents of output file maps and auxilliary file paths generated
implicitly by the compiler itself.
rdar://37713856
These tests were relying on sourcekitd parsing as frontend instead of
using the driver. Update them now to avoid churn when we fix command
line argument parsing in sourcekit.
The changes from clang-importer-sdk to clang-importer-sdk-nosource -I %t
are because clang-importer-sdk implies using -enable-source-import.
Rather than hack them up to use -Xfrontend, it is cleaner to just stop
using source import at all for these tests. Incidentally, this improved
fidelity in a few places. When using the generated swift modules we
also need to pass a target triple to sourcekit, which exposed some tests
that had mac-specific data. This is a systemic issue for sourcekit
tests, but for now just make those few specific tests that we had
problems with run only on mac.
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
The original hope was we could make these heuristics really good, but
since that is not currently in sight (and may never be), we want to be
able to turn them off. For now, just plumb through an internal flag to
control the behaviour. A future change will customize the behaviour in
SourceKit.
rdar://31113161
With broken code you can end up with non-postfix completions when
searching for inner operators, which you never want because you end up
creating compound results like "fooUIColor".
rdar://problem/34145229
When completing in an if/while/guard statement condition that expects a
boolean, add the code-completion type relation for Bool. We already had
this for repeat-while.
rdar://problem/26509084
For normal completions it behaves the same as PostfixExprBeginning, but
it provides a hook for clients to provide a custom completion for this
position. For example, you might want to a x ..< y snippet in this
position.
rdar://problem/29910383
When using completion options that will allow the lone "." completion,
provide that result when in contexts that expect an enum type. Note:
this is a crappy approximationg for whether the type can have "implicit
member expression" syntax, since uninhabited enums should not support
it, and many non-enum types should. However, it is currently expensive
to compute the accurate answer and this approximation is good enough for
some clients.
rdar://problem/31260505
The filter name isn't helpful if you want to make rules about specific
overloads - e.g. only show the [Int] subscript on Array.
rdar://problem/28920034
`FreeTypeVariableBinding::GenericParameters` mode allowed to bind
all free type variables with fresh generic parameter types, which
is incorrect (at least) if there are multiple generic solutions
present, because such parameters couldn't be compared.
This mode was used for code completion, which is now switched to use
`FreeTypeVariableBinding::UnresolvedType` instead.
We don't care what the USRs are here, we were just using them to avoid
results slipping in between the start of the structure and the module
name. This patch does that in a way that doesn't use the USR.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
* If "required" or "convenience" is specified, emit only initializers
* If "final" or "open" is specified, don't emit initializers or typealias
* If "typealias" is specified, emit only associated type implementation
* Emit "override" or "required" modifier for initializers
* Emit access modifier for initializers
* Emit designated initializers even if "override" is specified
* Don't emit inheritance clause for associated type implentation
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
The high weight on semantic context turns out to give a lot of
unreasonable completions on common types. For example
[0].ma<here>
was suggesting withUnsafeMutable... over map.
rdar://problem/27393776
Right now 'fileprivate' is parsed as an alias for 'private' (or
perhaps vice versa, since the semantics of 'private' haven't changed
yet). This allows us to migrate code to 'fileprivate' without waiting
for the full implementation.
The index may be at the end of the ArrayRef of chunks if the completion
ends with a simple parameter with no type annotation. Check that the
index is in-bounds before adding text.
rdar://problem/26273906
Surface these results in the codecomplete code path (they're already
there in the codecomplete.open code path) so we can use them from IDEs.
For now, just use ad-hoc filtering to show them when the type matches
(or there is no expected type). Ideally we would make this filtering
configurable like we do in the codecomplete.open code path.
rdar://problem/25836544
Code completion had the ability to use declarations to provide better
code completion results for postfix completions, e.g., calls to
functions/methods, but it wasn't trying to get these declarations from
anywhere. Now, get these declarations from the solution to the
constraint system.
The impetus for this is to use default-argument information from the
declaration rather than the type, but plumbing this information
through also means that we get proper "rethrows" annotations, covered
by <rdar://problem/21010193>, and more specific completions in a
number of other places.
Fixes <rdar://problem/21010193>.
* A bunch of them require objc_interop because they import code containing
Objective-C.
* Many others fail on Ubuntu 14.04 because the C++ there doesn't have a
functional std::regex implementation which is required by the
`complete-test` tool.
It may be possible to adjust some of these tests in the future to not
need these extra requirements, but this is a straightforward way to
clean up Linux test results for now.
