In case of ambigous expression/global completions, we call `getValueCompletionsInDeclContext` multiple times for the amigous solutions to the constraint system. This can cause modules to be included multiple times in `RequestedCachedResults` and thus global results from these modules are reported multiple times. Make `RequestedCachedResults` a set so we don’t get duplicate results.
rdar://92048610
`CodeCompletioString::getName()` was used only as the sorting keys in
`CodeCompletionContext::sortCompletionResults()` which is effectively
deprecated. There's no reason to check them in `swift-ide-test`. Instead,
check `printCodeCompletionResultFilterName()` that is actually used for
filtering.
This seems more correct than OtherModule, and means they're treated as
low-priority results for the session-based completion APIs. With default
options that means won't be shown in global completion results but will be
once there's some matching filter text. It also sorts them below any symbols
that actually come from other modules, which is desirable, since most symbols
don't need to be module qualified.
The SemanticContextKind change doesn't seem to affect Xcode's handling of the
results.
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)
`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.
This folds member access on types to a TypeExpr if the member
resolves to a nested type.
This allows [Foo.Bar]() to become an ApplyExpr of a TypeExpr,
rather than an ApplyExpr of an array literal; previously,
only [Foo]() worked.
Two cases that are still unsupported:
1) If G is a generic type and T is a generic typealias, then
G.T<X> cannot be folded to a TypeExpr, because we cannot
represent a generic typealias with an unbound generic
parent type. Such lookups remain member lookups, where
Sema first opens the base type to produce a bound generic
type G<$T0>, and then resolves the generic typealias
member on that.
2) If T is a generic parameter and X is an associated type,
T.X is not folded down to a TypeExpr either.
Fixes <rdar://problem/16849958>.
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.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
The brief explanation is that we are using the type-checker in a
questionable way where for various reasons we can type-check the same
"context" expression more than once. Until we figure out how to stop
doing that, at least avoid this obvious source of issues with ErrorType
showing up during the initial (poor) typecheck and then blocking
progress when we do a more specific check later.
rdar://problem/26462306
rdar://problem/25248190
...into separate prefix, postfix and infix operators. Also incidentally
make the whitespace around operators special so we can decide when to
skip over it. Tested in SourceKit.
Swift SVN r32468
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
This allows us to start code-completing postfix operators (generally !,
++, and --), which lays some of the groundwork for completing the much
more interesting infix operators.
These only show up when in postfix position
x<here>
For rdar://problem/22460167
Swift SVN r32355
Global variables from the same source file are more like locals when
writing top-level code, particularly in Playgrounds. Other declarations
(types, global functions, etc.) are unaffected.
rdar://problem/22329905
Swift SVN r31992
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
