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.
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.
The archetype builder was improperly propagating the requirement
source of a same-type requirement down to the inferred same-type
requirements for the nested types, causing a huge number of redundant
same-type requirements to show up in the canonical generic signatures
used for mangling. Mark such same-type requirements as inferred, which
shrinks the mangled name of LazyCollectionType.flatten from 4844 bytes
to 358 bytes.
Fixes rdar://problem/22861623.
Swift SVN r32356
The getConformsTo() callback was responsible for forcing the
collection of the requirements directly placed on an associated type,
which then get added to the archetype builder. This resulted in an
unhealthy dependency on the list of protocols attached to TypeDecl
(which should go away). Instead, retrieve the requirements from the
associated type's archetype (once it's been computed) or directly from
its list of "inherited" types (while we're building the generic
signature for the protocol itself).
Swift SVN r31332
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
generic parameter 'T' is not used in function signature
func f8<T> (x: Int) {}
This commit takes Jordan't comments on r28181 into account:
- it produces a shorter error message
- it does not change the compiler_crashers_fixed test and add a new expected error instead
Swift SVN r28194
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
There is no way to infer the generic parameter 'T' if it is not used in function signature
func f8<T> (x: Int) {}
^
Swift SVN r28181
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
This reverts commit r23030.
This puts non-primary archetypes back in the all-archetypes list,
which is the deepest underlying problem behind
rdar://problem/19049566.
Conflicts:
lib/AST/ArchetypeBuilder.cpp
validation-test/compiler_crashers/0033-error.swift
validation-test/compiler_crashers/035-multiple-typecheck-segfault.swift
Swift SVN r24333
The archetype builder is responsible for figuring out what should go
into a generic signature anyway, so move the generic signature
creation there. This will also allow us to eliminate some code
duplication across Sema and AST.
Fixes compiler crasher 033.
Swift SVN r23030
This will turn into "exactly" in a future commit, when we can build a
generic signature from an archetype builder (directly) and compare the
results.
Swift SVN r23010
Extend the contract for enumerateRequirements() a bit to preserve
archetype-to-archetype same-type constraints. Use that extra
information in the debug dump. NFC elsewhere.
Swift SVN r23008
This pushes some of the extra same-type requirements introduced in r22649 into the generic signature. Doesn’t really have an effect outside of extending generic signatures slightly.
Swift SVN r22680
When we have two protocol conformance requirements for the same type
T, and each of those protocols has an associated type with a given
(shared) name N, infer a same-type requirement between the two. Only
really enabled for testing now; it doesn't feed into general type
checking yet.
Swift SVN r22649
Whenever we add a requirement, we now know
(1) Why we added the requirement, e.g., whether it was explicitly written, inferred from a signature, or introduced by an outer scope.
(2) Where in the source code that requirement originated.
Also add a debugging flag for dumping the archetype builder information, so we can write tests against it.
This is effectively NFC, but it's infrastructure to help a number of requirements-related tasks.
Swift SVN r22638
When a specialization of a generic type occurs within the signature of
a generic function, it implies that the generic arguments meet the
requirements of the generic type. For example, in
func printHashes<K, V>(dict : Dictionary<K, V>) {
for (k, v) in dict {
print("\(k.hashValue())\n")
}
}
the presence of Dictionary<K, V> in the signature implies that K and V
meet the requirements on Dictionary's generic parameters, i.e., that K
is Hashable. Thus, infer that K is Hashable in printHashes().
Fixes the easy part of <rdar://problem/14691708>. Same-type and
superclass requirements are more interesting.
<rdar://problem/14691708>
Swift SVN r7574
