Basic implementatation of SE-0021, naming functions with argument
labels. Handle parsing of compound function names in various
unqualified-identifier productions, updating the AST representation of
various expressions from Identifiers to DeclNames. The result doesn't
capture all of the source locations we want; more on that later.
As part of this, remove the parsing code for the "selector-style"
method names, since we now have a replacement. The feature was never
publicized and doesn't make sense in Swift, so zap it outright.
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.
where we type check the destination first, then apply its type to the source.
This allows us to get diagnostics for assignments that are as good as PBD
initializers and other cases.
Swift SVN r31404
and diagnoseGeneralConversionFailure(). The previous approach of trying
to dig into anchors would often lead to complaining about types at
different levels in the same diagnostic, and the complexity of the former
code isn't needed now that other changes have landed.
Swift SVN r31036
which we have a contextual type that was the failure reason. These are a bit
longer but also more explicit than the previous diagnostics.
Swift SVN r30669
we can start taking advantage of ambiguously typed subexpressions in CSDiags. We
start by validating the callee function of ApplyExprs, which substantially improves
our abilities to generate precise diagnostics about malformed calls.
This is the minimal introduction of this concept to CSDiags, a lot of refactoring
is yet to come, however, this is enough to resolve:
<rdar://problem/21080030> Bad diagnostic for invalid method call in boolean expression
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
one of the testcases from:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
and a bunch of other places where we got weird "unexpected trailing closure"
diagnostics that made no sense. As usual, it is two steps forward and one step back,
as this exposed some other weird latent issues like:
<rdar://problem/21900971> QoI: Bogus conversion error in generics case
Swift SVN r30429
It's safe to do this as long as the protocol has already been fully type-checked,
and we can guarantee that if the protocol lives in another module.
The next commit shows why this is useful: "extension dispatch_queue_t" is much
nicer than "extension OS_dispatch_queue".
Swift SVN r30099
facilities used by operators etc. This required a bunch of changes to make
the diagnostics changes strictly an improvement:
- Teach the new path about calls to TypeExprs.
- Teach evaluateCloseness some simple things about varargs.
- Make the generic diagnosis logic produce a better error when there is
exactly one match.
Overall, the resultant diagnostics are a step forward: we now produce candidate
set notes more uniformly, and the messages about some existing ones are
more specific. This is just another stepping stone towards progress though.
Swift SVN r30057
We're not sure when or if we want 'final' on protocol extension
members, so accept it but don't complain one way or another. We zap
this early on so that we don't end up printing it in generated
interfaces. Fixes rdar://problem/21112901.
Swift SVN r29040
Based on Dave’s hack, this allows one to define a “default implementation” as, e.g.,
protocol P {
func foo()
}
extension P {
final func foo() { … }
}
Swift SVN r28949
This information keeps declarations in differently-constrained
protocol extensions separate. Fixes rdar://problem/21060743 and
enables the (N+1)st iteration of the default implementations hack.
Swift SVN r28887
This allows us to overload properties and subscripts with the same
signature in differently-constrained protocol extensions. Previously,
such overloads would be considered to be erroneous redeclarations.
Swift SVN r28610
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
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
Within the where clause of a constrained (protocol) extension, allow
us to find associated types of that protocol and anything it inherits
via unqualified lookup, e.g.,
extension SequenceType where Generator.Element : Equatable { }
rather than
extension SequenceType where Self.Generator.Element : Equatable { }
Implements rdar://problem/20722467.
Swift SVN r28208
AnyObject won't always be a protocol, and it may be de-protocol'ified
well before we get the ability to extend an arbitrary type (if that
ever happens), so ban this for now.
Swift SVN r28120
We might be looking at a protocol requirement, which conforms to a
protocol but has a null conformance. Also, don't bother looking at
completeness: it doesn't matter. Fixes rdar://problem/20608438.
Swift SVN r27860
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
Inference of type witnesses for associated types was previously
implemented as part of value witness matching in the constraint
solver. This led to a number of serious problems, including:
- Recursion problems with the solver hunting for a type witness,
which triggers more attemts to match value witnesses...
- Arbitrarily crummy attempts to break the recursion causing
type-check failures in fun places.
- Ordering dependencies abound: different results depending on which
value witnesses were satisfied first, failures because of the order
in which we attempted to infer type witnesses, etc.
This new implementation of type witness inference uses a separate pass
that occurs whenever we're looking for any type witness, and solves
all of the type witnesses within a given conformance
simultaneously. We still look at potential value witnesses to infer
type witnesses, but we match them structurally, without invoking the
constraint solver.
There are a few caveats to this implementation:
* We're not currently able to infer type witnesses from value
witnesses that are global operators, so some tricks involving global
operators (*cough* ~> *cough*) might require some manually-specified
type witnesses. Note that the standard library doesn't include any
such cases.
* Yes, it's another kind of solver. At simple one, fortunately.
On the other hand, this implementation should be a big step forward:
* It's far more predictable, order-invariant, and non-recursive.
* The diagnostics for failures to infer type witnesses have
improved.
Fixes rdar://problem/20598513.
Swift SVN r27616
Handle substitutions properly when a typealias declared in a protocol
extension is used to satisfy an associated type requirement. Fixes
rdar://problem/20564605.
Swift SVN r27490
For structs/enums, this was already the case. For classes, we simply
need to ensure that we always look at the extensions of protocols to
which the class conforms.
Swift SVN r26773
