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.
A decl’s full GenericSignature is set during validateGenericTypeSignature().
Then during ConstraintSystem::openTypes(), in ReplaceDependentTypes, the GenericArgs list is built from the generic signature (via getGenericParamTypes()) and passed into a new BoundGenericType.
In BoundGenericType::getSubstitutions(), the GenericArgs are assumed to match getGenericParamsOfContext()->getParams().
However, in reality, the GenericArgs include all levels of generic args, whereas getGenericParamsOfContext() are the params of the innermost context only, so the params array is accessed past its end.
This commit changes NominalTypeDecl::getGenericParamTypes() to return the innermost params, in order to match the output of BoundGenericType::getGenericArgs(). For clarity and to hopefully prevent future confusion, we also rename getGenericParamTypes() to getInnermostGenericParamTypes().
Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This is necessary for some other work I'm doing, which really wants
paramdecls to have reasonable declcontexts. It is also a small step
towards generic subscripts.
Aligning with our recent changes for Clang doc comments, the three new fields for Swift are
"- keyword:", "- recommended:", and "- recommendedover:". We also manifest their contents in code
completion results to guide users to choose the right API.
When auto-completing import decls, we should prioritize not-yet imported modules
over already-imported modules. To do so, we mark the latter with not-recommended tag.
Similar with @keyword, manifesting @recommended and @recommendedover content in code
completion results can help IDE users to choose the right API in the long candidate list.
This commit extract these two attributes from Clang doc comments and insert/cache them in
code completion results.
rdar://23101030 and rdar://23101029
Conventionally, code completion results are matched with user input solely by
names. However, names are limited in expressiveness. From this comments, we start to
decorate code completion results with @keywords fields extracted from Clang doc comments.
These fields are added by API authors to comment the decl with information that
is not manifested clear enough through names. Code completion users' typing of the
keyword leads to the corresponding code completion results being selected as well.
Keywords can be arbitrarily long and can be multiple.
For instance, a function called "index()" has "@keyword find" in its doc comment.
Users' typing of "find" leads to "index()" being selected in the code completion list.
