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
<rdar://20494686>
String itsef should only expose Unicode-correct algorithms, like proper
substring/prefix/suffix search, enumerating words/lines/paragraphs, case
folding etc. Promoting sequence-centric algorithms to methods on String
is not acceptable since it invites users to write wrong code. Thus,
String has to lose its SequenceType conformance.
Nevertheless, we recognize that sometimes it is useful to manipulate the
String contents on lower levels (UTF-8, UTF-16, Unicode scalars,
extended grapheme clusters), for example, when implementing high-level
Unicode operations, so we can't remove low-level operations
altogether. For this reason, String provides nested "views" for the
first three low-level representations, but grapheme clusters were in a
privileged position -- String itself is a collection of grapheme
clusters. We propose to add a characters view that will represent the
String as a collection of Character values.
Swift SVN r28065
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
If you want to make the parameter and argument label the same in
places where you don't get the argument label for free (i.e., the
first parameter of a function or a parameter of a subscript),
double-up the identifier:
func translate(dx dx: Int, dy: Int) { }
Make this a warning with Fix-Its to ease migration. Part of
rdar://problem/17218256.
Swift SVN r27715
Fixes the crash in rdar://problem/20564378. In these cases, we end up
swallowing some diagnostics. That will be addressed in a subsequent
commit.
Swift SVN r27436
Consistently open all references into existentials into
opened-existential archetypes within the constraint solver. Then,
during constraint application, use OpenExistentialExprs to record in
the AST where an existential is opened into an archetype, then use
that archetype throughout the subexpression. This simplifies the
overall representation, since we don't end up with a mix of operations
on existentials and operations on archetypes; it's all archetypes,
which tend to have better support down the line in SILGen already.
Start simplifying the code in SILGen by taking away the existential
paths that are no longer needed. I suspect there are more
simplifications to be had here.
The rules for placing OpenExistentialExprs are still a bit ad hoc;
this will get cleaned up later so that we can centralize that
information. Indeed, the one regression in the compiler-crasher suite
is because we're not closing out an open existential along an error
path.
Swift SVN r27230
Per discussion on the list. From now on, when you fix a compiler_crashers
test case, move it to compiler_crashers_fixed so that we get no-asserts and
ASan coverage.
Swift SVN r27055
