This adds an `appendInterpolation` overload to
`DefaultStringInterpolation` that includes a parameter for providing a
default string when the value to interpolate is `nil`. This allows this
kind of usage:
```swift
let age: Int? = nil
print("Your age is \(age, default: "timeless")")
// Prints "Your age is timeless"
```
The change includes an additional fixit when optional values are
interpolated, with a suggestion to use this `default:` parameter.
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
Similar to 4cf7426698 but for the case
when the completion is in a default argument expression rather than
initializer. Fixed to grab either the initializer or default argument if
there is one.
Strings are a single token, so the previous check would treat
completions inside string interpolations as being outside of the
initializer.
Grab the end of the token from the Lexer, but wrap in a context check to
avoid performing that for every declaration found in the lookup.
Resolves rdar://70833348
Calculate and set the type relation in each result building logic which
knows the actual result type.
CodeCompletionResultBuilder couldn't know the actual result type. From
the declaration alone, it cannot know the correct result type because it
doesn't know how the declaration is used (e.g. calling? referencing by
compound name? curried?)
When a completion happens in a key position and the value expression
is missing. This allows type checker to use TypeVariable so it increases
the chance to type check them successfully.
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
- Use `performParseAndResolveImportsOnly()` to invoke the frontend
- Do `bindExtensions()` in `ide::typeCheckContextUntil()`
- Typecheck preceding `TopLevelCodeDecl`s only if the compleiton is in
a `TopLevelCodeDecl`
- Other related tweaks
rdar://problem/56636747
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>.
(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
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
This fixes various issues with getting no code-completion in top-level
code containing array/dictionary sugar, such as:
```
for x in [<HERE>] {}
for x in [1: 2, <HERE>] {}
```
And also removes the index variable from completions inside the sequence
(it was coming through as a local variable with <<error type>>).
rdar://problem/33884082
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 a declaration is marked deprecated (but not unavailable) we want to
mark it as "not recommended" so that users know this probably isn't what
you want. We already do something like this in Clang code completions of
deprecated ObjC declarations.
rdar://problem/26335424
With the tests updated to account for not having the correct behaviour
for brace-stmt items from after the code-completion point. That part
turns out to be harder to fix.
This reverts commit a5325e6281.
for i in <here> // should *not* show 'i'
for i in ... where <here> // should show 'i'
for i in ... { <here> // should show 'i'
Part of rdar://problem/24873625
We were miscalculating 'isRightBound' when the RHS was a code-completion
token leading to missing completions in unspaced binary expressions
1+<here>
1...<here>
rdar://problem/24278699
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
