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
Also restore some diagnostics in TypeCheckType that should have
migrated with the attributes. In particular, diagnose cases where
we have @autoclosure with any function type repr with a non-Void
input type.
Resolves SR-5296
`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.
Substitution into a generic function type produces non-canonical
generic signatures. This functionality should either be removed or be
completely rewritten to properly use the GenericSignatureBuilder. For
now, disable this one client's unsafe use of it.
This does regression code-completion results slightly, where we were
depending on OverrideFilteringConsumer's behavior to filter out some
redundant results. I've captured the work to fix this properly in
rdar://problem/31245556.
There is never any reason for a transform to treat a ParenType
differently from the underlying type itself. Calling the given
function with ParenTypes is a source of bugs where they get
desugared on accident. Make transform() skip the function
entirely for ParenTypes, and remove a spot where we were
checking explicitly.
If a sugared type desugars to a substitutable type, we would
return the replacement type without the sugar. I think in
practice this meant that ParenType would be lost sometimes.
Preserving this correctly is required for an upcoming CSDiag
change.
Note that there's a minor source-breaking change with enum
case constructors here. I've filed <rdar://problem/27261929>
to track sorting it out in Swift 3 mode.
Also an upcoming patch fixes another related issue and adds more
tests for case constructors.
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.
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.
Completion after dot inside an init (or any other parent expr with a
nominal type) was incorrectly looking at the types of parent expressions
whenever the base type was not a nominal (even an lvalue of a nominal
wasn't working). This code to look at the type of the parent was never
correct, and fortunately the type-checking issues that prompted it to be
added in the first place have since been fixed, so we can just delete
it.
rdar://problem/25773358
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>.
This is a big refactoring of resolveTypeInContext() which makes
the function clearer to understand by merging various special
cases and generalizing the logic for walking parent and superclass
contexts to cover more cases.
This improves typealiases in protocols a bit:
1) Previously a typealias in a protocol either had to be concrete,
or consist of a single path of member types from Self, eg
Self.A.B. Lift this restriction, so we can now write things like
protocol Fireworks {
associatedtype Exploding
typealias Exploder = Exploding -> [Exploding]
}
2) Protocol typealiases can now be accessed via qualified lookup
on concrete types. Getting this working for unqualified lookup
requires further refactorings which will be in a subsequent
patch.
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
It was pointed out to me that this syntax is legal (d'oh). Maybe we
should delete the extra spaces when we insert the ".", but otherwise
this is working as-is.
This reverts commit 1878be2c1f.
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
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
