Properly implementing a class whose methods capture variables
defined in the outer scope requires adding the captures as
hidden vars in the class and initializers, and seems
non-trivial.
Just diagnose this case for now instead of crashing.
Fixes <rdar://problem/20853958>.
Swift SVN r28481
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
When performing unqualified lookup within a type context (or method
thereof) that is a protocol or a protocol extension, use the Self
archetype of the protocol or extension so we look in types implied by
the requirements as well. Part of rdar://problem/20509152, fixing the
example provided in rdar://problem/20694545.
Swift SVN r28363
Members of protocols found via unqualified name lookup are mapped to
their corresponding witnesses, as we do for qualified name
lookup. This is the bulk of the compiler changes for
rdar://problem/20509152. Performing this mapping for unqualified name
lookup of types will follow.
Swift SVN r28333
The code would generate different diagnosics depending on
the cycle having length 1 or longer. The length 1 case
was broken if the path had a prefix that wasn't part
of the cycle, eg if we have C : A, A : A and visit C
first.
Swift SVN r28317
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
we parsed, otherwise the type checker gets confused later. This fixes these
regressions:
Swift :: compiler_crashers_fixed/0725-swift-type-walk.swift
Swift :: compiler_crashers_fixed/0742-swift-metatypetype-get.swift
Swift :: compiler_crashers_fixed/1501-swift-diagnosticengine-flushactivediagnostic.swift
Swift :: compiler_crashers_fixed/1705-vtable.swift
Also, that patch fixed 0791-swift-type-walk.swift, so mark it as not crashing.
Swift SVN r28108
The culprit happened to be a type representation cloner for tuple type
representations that didn't actually clone anything. Introduce an
AST-level verifier that makes sure we catch any archetypes that slip
into interface types earlier in the future.
Fixes rdar://problem/18796397 and the three dupes I've found so far.
Swift SVN r28080
<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
