Conformance checking selects more-specialized value
witnesses. Therefore, teach type witness inference to rank its
solutions by comparing value witnesses. Part of rdar://problem/21883828.
Swift SVN r30423
Don't crash here when we need to add '_' to a parameter list. However,
while we're here, stop trying to emit Fix-Its for implicit
declarations and stop worrying about introducing a ':' after the name
for functions such as
func foo(Int) { ... }
because they're no longer permitted. Fixes rdar://problem/21333445.
Swift SVN r30195
Replace some dodgy recursion-breaking code in the archetype builder
that was meant to deal with recursive associated type requirements
(which our model does not currently support) with a more robust
approach. Fixes rdar://problem/20682090 and rdar://problem/21738889.
Swift SVN r30039
The recursive type matcher is used to match two types together,
calling out to a separate implementation subclass to cope with any
mismatches that occur. Use this type matcher to simplify the
expression of the requirement/witness matching used by inference of
type witnesses. More clients to come...
Swift SVN r29749
When a given associated type gets two conflicting inferences from the
same signature, diagnose it without crashing. Fixes
rdar://problem/21304164.
Swift SVN r29412
This warning previously had no way to be silenced. I don't expect people to
actually use this much, but it seems important for completeness.
Swift SVN r29091
When an optional requirement goes unfulfilled by a conformance, and
there is a non-@objc declaration with that name in the type/extension
declaring conformance, warn that it does not satisfy the optional
requirement. Sadly, this diagnostic is long because there are notes
for the two potential fixes: add @objc to try to conform, or move the
declaration elsewhere to silence the compiler.
Fixes rdar://problem/20219297.
Swift SVN r28908
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
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
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
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
When we're checking for a particular witness in a protocol conformance
because the result is needed elsewhere, capture the diagnostic we
would emit and then store it in the ASTContext. We will emit these
diagnostics when doing the full check of the conformance. Addresses
the rest of rdar://problem/20564378.
Swift SVN r27449
When comparing a requirement to a witness for @objc protocols, strip
optionality out of the types and keep track of the optionality
differences separately. When we have actually matched a witness,
diagnose any unsafe (via an error) or ill-advised (via a warning)
differences, providing Fix-Its to update the optionality.
This change addresses a usable problem introduced by the fix to
rdar://problem/18383574: witnesses for optional requirements of @objc
protocols could previously have completely wrong optionality, and we
would "allow" it by not actually matching the witness to the
requirement. Then it would happen to work at runtime because it's
@objc. Now, we match those witnesses and diagnose issues, with Fix-Its
to clean up the user's code.
Addresses rdar://problem/19656106.
Swift SVN r24939
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
When we match a witness to a requirement in a protocol, we do so based
on the Swift name (which is correct). When the requirement is @objc
(because it is in an @objc protocol), also check that the Objective-C
selectors of the witness match those of the requirement.
Fixes the majority of rdar://problem/18383574.
Swift SVN r24829
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
When a non-final class satisfies a method requirement that returns
Self, it must do so with a method that also returns (dynamic)
Self. This ensures conformance will be inheritable, closing off an
awful type-safety hole <rdar://problem/16880016>. Other
non-contravariant uses of Self in the signatures of requirements cause
the protocol to be unusable by non-final classes.
I had to leave a tiny little gaping hole for the ~> operator, whose
removal is covered by <rdar://problem/17828741>. We can possibly put
this on firm footing with clever handling of generic witnesses, but
it's not important right now.
Swift SVN r20626
them to cover all declaration types.
This ensures that we reject attributes on declkinds where they don't make sense. I went so far
as to make the QoI decent when an attribute can only be applied to a single kind of declaration
to make sure the error message says "@IBAction is only valid on 'func' declarations" as well.
This resolves <rdar://problem/17681151> 'dynamic' accepted by the compiler where it shouldn't be
Swift SVN r19982
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
There's a lot more work to do here, but start to categorize tests
along the lines of what a specification might look like, with
directories (chapters) for basic concepts, declarations, expressions,
statements, etc.
Swift SVN r9958
