Before:
- protocol type 'Listener' does not conform to protocol 'Listener' because
'Listener' is not declared @objc
- protocol type 'Listener' does not conform to protocol 'Listener' because
'Listener' defines static methods
After:
- using 'Listener' as a concrete type conforming to protocol 'Listener' is
not supported
- 'Listener' cannot be used as a type conforming to protocol 'Listener'
because 'Listener' has static requirements
I removed the mention of '@objc' even though @objc protocols are more freely
self-conforming because it was confusing people working with pure Swift code.
Making this actually work for pure Swift protocols is tracked by
rdar://problem/21341337.
This also fixes a few cases where we were emitting this message even for
two completely unrelated protocols.
rdar://problem/21525618
Swift SVN r30698
This reverts revision r30688. The patch needs more work, because it flags a
valid case as circular, see r15054, "Relax restriction on indirectly-self-
recursive protocol conformances. (rdar://problem/16306715)".
Swift SVN r30690
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
Otherwise, we end up with declarations with public access that do not
have public 'self' types. These declarations can then be used by other
modules, which may end up trying to access non-external symbols.
This closes a loophole currently in use by the standard library, so
the '_prext_ReverseIndexType' and '_ReverseCollectionType' protocols
become public for now. In order to keep the API impact minimized,
extensions involving these protocols now extend them directly, so that
all of the "private" stuff shows up in one place in the generated
interface. This is not a long-term solution, but it's no worse than
the rest of the underscore rules in the standard library.
rdar://problem/21380336 tracks relaxing access restrictions for protocol
conformances when the witnesses come from a different type, like a
protocol extension. This requires some SILGen work to do correctly.
Finishes rdar://problem/21559986
Swift SVN r30612
directly into the diagnostics subsystem. This ensures a more consistent
treatment of type printing (e.g. catches a case where a diagnostic didn't
single quote the type) and gives these diagnostics access to "aka".
Swift SVN r30609
In a CallExpr, evaluate the function subexpr before the argument subexpr,
in prep for being able to use this type info to propagate them onto the
arguments when available. NFC.
Swift SVN r30567
Core Data synthesizes Key-Value-Coding-compliant accessors for @NSManaged
properties, but Swift won't allow them to be called without predeclaring
them.
In practice, '@NSManaged' on a method is the same as 'dynamic', except
you /can't/ provide a body and overriding it won't work. This is not the
long-term model we want (see rdar://problem/20829214), but it fixes a
short-term issue with an unfortunate workaround (go through
mutableOrderedSetValueForKey(_:) and similar methods).
rdar://problem/17583057
Swift SVN r30523
Generic subclasses of @objc classes are thus no longer @objc, but still
have implicitly @objc members.
Explicit @objc on generic classes or classes that inherit from @objc
classes is now forbidden with a diagnostic. Users need to know that
while they can override Objective-C methods and properties in such
a class, they cannot refer to the class by name from Objective-C code,
since it will not appear in the bridging header.
Fixes <rdar://problem/21342574>.
Swift SVN r30494
detailed analysis of callees, which give us overload sets in more cases,
producing notes more consistently, and producing much better diagnostics
for the curried cases in test/Constraints/diagnostics.swift.
This also allows us to eliminate getCalleeName, which simplifies things
in CSDiags.
Swift SVN r30491
This changes the diagnostic text when a variable cannot be marked potentially unavailable
so that it does not explicitly use the long-style form of @available:
It changes:
"stored properties cannot be marked potentially unavailable with 'introduced='"
to:
"stored properties cannot be marked potentially unavailable with '@available'"
Swift SVN r30446
fixing:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
<rdar://problem/21829141> BOGUS: unexpected trailing closure
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
Swift SVN r30443
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
Otherwise, people subclassing NSView will accidentally call NSView.print
when they're trying to call Swift.print.
rdar://problem/18309853
Swift SVN r30334
Update the diagnostic emitted when an accessor override is less available than the
declaration it overrides to mention the accessor kind and the name of the property rather
than just the accessor declaration name, which is '_'.
rdar://problem/20427938
Swift SVN r30319
value, and use that to rank a problem as very specific. This required indicating a difference
between singular argument mismatch vs self mismatch and single-argument mismatch (which is very
specific) as being different from the argument list in general mismatching (which matters to
differentiate argument lists that contain a single argument).
These extra mechanics combine to fix <rdar://problem/21362748> [WWDC Lab] QoI: cannot subscript a value of type '[Int]?' with an index of type 'Int'
Swift SVN r30305
Adjust our placement of RebindSelfInConstructorExpr to fall outside of
a force-value expression (!), allowing, e.g.,
self.init(somethingThatCanFail: x)!
and
super.init(somehtingThatCanFail: x)!
Start suggesting '!' when chaining/delegating to a failable
initializer from a non-failable one, in addition to suggesting that
the enclosing initializer become failable.
Note that DI cannot handle this yet, so this is only the Sema part of
rdar://problem/18497407.
Swift SVN r30219
Instead of requiring the user to disambiguate where an implied
protocol conformance goes---which they really, really don't care
about---just pick an arbitrary-but-deterministic location for the
conformance, which corresponds to the file unit in which the witness
table will be emitted. Fixes rdar://problem/21538899.
Swift SVN r30168
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
Now for:
let req = NSURLRequest(URL: NSURL(string: "<some url>")!)?
instead of producing:
test.swift:2:58: error: could not find an overload for 'init' that accepts the supplied
we produce the correct diagnostic, with a fixit:
error: cannot use optional chaining on non-optional value of type 'NSURLRequest'
let req = NSURLRequest(URL: NSURL(string: "<some url>")!)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
This also consolidates some existing diagnostics to improve their wording.
Swift SVN r30049
This is a straight-up "oops". You could always get to these typealiases via
the protocol, but like the member requirements you should have to say so.
Swift SVN r29952
- Fix a diagnostic to not include redundant ''s around a type name.
- Rework CleanupIllFormedExpression to be simpler and to not
unconditionally destroy data when it doesn't. This makes a code
completion test a bit more precise.
- Completely revamp getTypeOfIndependentSubExpression, to return the
subexpression produced by type checking instead of just a type. This
is important for cases when type checking changes the root of the AST
(e.g. resolving an unresolved_dot_expr) and allows us to eliminate
grungy and unsafe recovery code that was in place to work around this.
The last point makes the examples in Constraints/lvalues.swift better (giving
a somewhat generic error instead of an specific-but-incorrect error that 'z'
is immutable), but more importantly, it fixes a class of crashers like
<rdar://problem/21369926> Malformed Swift Enums crash playground service
where we'd end up with a LiteralExpr typed as Int instead of a Builtin integer
type of some sort.
Swift SVN r29932
when we're diagnosing a value member constraint but have resolved the base, then the
member must not exist. Diagnose this with a specific message.
Swift SVN r29908
- Enhance subscript diagnostics to chase into the constraint system to find
overload candidates that failed to match so we can rank and diagnose
subscript ambiguities using the same mechanics we have for operators.
- Implement a copy of suggestPotentialOverloads based on the new mechanics
for overload set resolution. This allows us to diagnose these in a more
detailed way, but for now we're keeping it as similar to the old system as
possible. The old version to be removed once the last client moves off it.
- Add a bunch of testcases to decl/subscript/subscripting.swift where we are
doing unfortunate things still.
Swift SVN r29810
Previously, we were simply walking over the requirements of each of
the associated types, which meant that we weren't considering
same-type constraints. Also cleans up the diagnostics a little bit and
eliminates some extra computation whose results were getting thrown
away.
Swift SVN r29793
These classes don't show up well in generated headers (rdar://problem/20855568),
can't actually be allocated from Objective-C (rdar://problem/17184317), and
make the story of "what is exposed to Objective-C" more complicated. Better
to just disallow them.
All classes are still "id-compatible" in that they can be converted to
AnyObject and passed to Objective-C, they secretly implement NSObjectProtocol
(via our SwiftObject root class), and their members can still be individually
exposed to Objective-C.
The frontend flag -disable-objc-attr-requires-foundation-module will disable
this requirement as well, which is still necessary for both the standard
library and a variety of tests I didn't feel like transforming.
Swift SVN r29760
It looks like we were checking in the wrong place, as a result we didn't
catch stuff like
class G<T : AnyObject> {}
_ = G<P>()
This would crash later in IRGen.
Make the conformsToProtocol() check do the right thing, and remove some
other miscellaneous diagnostics in the process. Also, make the
"type 'T' does not conform to protocol 'P'" diagnostic a bit more
detailed.
Unfortunately in a few instances we lose a more descriptive diagnostic to
a general 'cannot invoke 'foo' with argument list of type 'T'' error. The
argument matching diagnostics need to be addressed anyway though.
Fixes <rdar://problem/20311619>.
Swift SVN r29737
