...replacing it with the new, after passing API review!
* The lazy free function has become a property.
* Before we could extend protocols, we lacked a means for value types to
share implementations, and each new lazy algorithm had to be added to
each of up to four types: LazySequence, LazyForwardCollection,
LazyBidirectionalCollection, and LazyRandomAccessCollection. These
generic adapters hid the usual algorithms by defining their own
versions that returned new lazy generic adapters. Now users can extend
just one of two protocols to do the same thing: LazySequenceType or
LazyCollectionType.
* To avoid making the code duplication worse than it already was, the
generic adapters mentioned above were used to add the lazy generic
algorithms around simpler adapters such as MapSequence that just
provided the basic requirements of SequenceType by applying a
transformation to some base sequence, resulting in deeply nested
generic types as shown here. Now, MapSequence is an instance of
LazySequenceType (and is renamed LazyMapSequence), and thus transmits
laziness to its algorithms automatically.
* Documentation comments have been rewritten.
* The .array property was retired
* various renamings
* A bunch of Gyb files were retired.
Swift SVN r30902
fixing <rdar://problem/22020088> QoI: missing member diagnostic on optional gives worse error message than existential/bound generic/etc
Swift SVN r30844
- Produce more specific diagnostics relating to different kinds of invalid
- add a testcase, nfc
- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of
Not including r30787 means that we still generate bogus diagnostics like:
[1, 2, 3].doesntExist(0) // expected-error {{type 'Int2048' does not conform to protocol 'IntegerLiteralConvertible'}}
But it is an existing and separable problem from the issues addressed here.
Swift SVN r30819
r30787 causes our tests to time out; the other commits depend on r30787.
Revert "revert part of my previous patch."
Revert "Produce more specific diagnostics relating to different kinds of invalid"
Revert "add a testcase, nfc"
Revert "- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of"
Revert "Fix places in the constraint solver where it would give up once a single "
Swift SVN r30805
Replace the Lazy-based implementations with open-coded implementations based on the _UnsafePartiallyInitializedContiguousArrayBuffer builder from the previous commit, so that we have control over the early-exit flow when an error interrupts the operation.
Swift SVN r30794
performMemberLookup, eliminating a ton of duplicated logic, but keeping the
same general behavior.
- Now that r30787 landed, we can have diagnoseGeneralMemberFailure inform
clients when a member lookup fails due to referencing a candidate decl of
ErrorType (i.e, it is already invalid somehow). When this happens, there is
no reason to diagnose a problem, because the original issue has been diagnosed
and anything we produce now is just garbage.
The second point cleans up a bunch of bogus diagnostics in the testsuite, which are
*actually* due to upstream error that are already diagnosed.
Swift SVN r30789
constraint failed, leaving a bunch of other solvable constraints laying
around in the system as inactive.
This is a problem for diagnostics emission, because it turns around and
reaches into the constraint system for some inactive constraint, assuming
that anything left could not be solved. The constraint system attempted to
solve this by taking the first failure and putting it into the failedConstraint
with the intention of driving diagnostics, but just because it happened to fail
first in constraint-solver-worklist-order doesn't mean it is the most pertinent
one to diagnose.
Swift SVN r30787
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
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
conversion failures, making a bunch of diagnostics more specific and useful.
UnavoidableFailures can be very helpful, but they can also be the first constraint
failure that the system happened to come across... which is not always the most
meaningful one. CSDiag's expr processing machinery has a generally better way of
narrowing down which ones make the most sense.
Swift SVN r30647
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
type check the subexpressions of a callexpr more consistently,
always checking the arguments independently (not just if one argument
is inout). This routes around issues handling tuples, and brings more
consistency to the experience. Factor this logic out and use it for
operators and subscripts as well.
Swift SVN r30583
independently (not just if one argument is inout). This routes around issues handling tuples,
and brings more consistency to the experience. Factor this logic out and use it for operators
and subscripts as well.
This improves a small collection of diagnostics, including the infamous:
// Infer incompatible type.
- func6(fn: {a,b->Float in 4.0 }) // expected-error {{cannot convert return expression of type 'Double' to expected return type 'Float'}}
+ func6(fn: {a,b->Float in 4.0 }) // expected-error {{cannot invoke 'func6' with an argument list of type '(fn: (_, _) -> Float)'}}
+ // expected-note @-1 {{expected an argument list of type '(fn: (Int, Int) -> Int)'}}
Swift SVN r30570
diagnose problems inside of them instead of punting on them completely.
This leads to substantially better error messages in many cases, fixing:
<rdar://problem/19870975> Incorrect diagnostic for failed member lookups within closures passed as arguments ("(_) -> _")
<rdar://problem/21883806> Bogus "'_' can only appear in a pattern or on the left side of an assignment" is back
<rdar://problem/20712541> QoI: Int/UInt mismatch produces useless error inside a block
and possibly others. We are not yet capitalizing on available type information we do
have about closure exprs, so there are some cases where we produce
"error: type of expression is ambiguous without more context"
when this isn't strictly true, but this is still a huge step forward.
Swift SVN r30547
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
rationalizing how it handles members and curried functions, also paving
the way for future improvements. This implements the infrastructure but
keeps the functionality the same (the only functionality change is that
it works a bit better with vardecls of function type).
Swift SVN r30464
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
return statements, or a return statement with no operand.
Also, fix a special-case diagnostic about converting a return
expression to (1) only apply to converting the actual return
expression, not an arbitrary sub-expression, and (2) use the
actual operand and return types, not the drilled-down types
that caused the failure.
Swift SVN r30420
DiscardAssignmentExpr's, because they require context to typecheck anyway
and doing so triggers bogus errors about _ needing to be on the LHS of an
assignment. There is a correct way to fix this, but layers of issues need
to be peeled off before that can happen.
This fixes <rdar://problem/21883806> Bogus "'_' can only appear in a pattern or on the left side of an assignment" is back
but the new diagnostic that is revealed now that this bogus one is removed is
also really bad.
Swift SVN r30369
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
- Remove all uses of CleanupIllFormedExpressionRAII from this file, which are now
unnecessary since this is handled at a higher level.
- Stop splatting ErrorType in the diagnostics stuff. This was formerly needed to
indicate that a diagnostic is emitted, but is now handled other ways. Removing
this enables the type checker to produce other follow on warnings in some cases
(e.g. var should be marked let).
- Remove an arbitrary limitation on unop and binops that didn't print an overload
candidate set with one entry, leading to better consistency in diagnostics, now
that all the pieces are in place to make this not be super annoying.
Swift SVN r30084
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
... by reimplementing the DiscardAssignmentExpr checker in MiscDiagnostics
instead of being in CSApply (which gets run on partial expression ASTs).
Also, when type checking and salvaging an expression fails, do not generate
structural diagnostics in addition to the type checker diagnostics, they are
just noise.
Swift SVN r29937
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
We used to produce:
test.swift:6:20: error: cannot subscript a value of type '[Int]?' with an index of type 'Int'
return foo.array[0]
^
with the recent subscript improvements we now produce:
error: result type 'Element' does not match expected type
which still isn't a great diagnosis, but at least is the correct problem.
Swift SVN r29867
expressions. Broadening from callexpr to apply expr (picking up operators) improves
several diagnostics in the testsuite, and is important to avoid regressions from an
upcoming patch.
Swift SVN r29821
- 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
ApplyExpr involved in the overload failure, wire it up to some of the
mechanics we have for more specific situations, including diagnosing
the last (known to me) mutation issues that weren't being specifically
diagnosed, as well as printing the candidate set in these cases.
Swift SVN r29797
This teaches overload constraint diagnosis to look at the resolved anchor
expression that fails (instead of assuming that it is the expr itself) and
walks up the AST to find the applyexpr in question. This allows us to give
much more specific diagnostics for overload resolution failures, and to give
much more specific location information.
Where before my recent patches we used to produce:
t.swift:2:3: error: cannot invoke 'assert' with an argument list of type '(Bool, String)'
assert(a != nil, "ASSERT COMPILATION ERROR")
^
t.swift:2:9: note: expected an argument list of type '(@autoclosure () -> Bool, @autoclosure () -> String, file: StaticString, line: UWord)'
assert(a != nil, "ASSERT COMPILATION ERROR")
^
with this and the other recent patches, we now produce:
t.swift:2:12: error: cannot invoke '!=' with an argument list of type '(Int, nil)'
assert(a != nil, "ASSERT COMPILATION ERROR")
~~^~~~~~
Swift SVN r29792
its diagnostics in post-order. Notably, this picks up support for if-expr, which
gives up much better diagnostics in ternary operators. For example, rdar://17224804
used to produce:
error: could not find an overload for '<=' that accepts the supplied arguments
var monthString = (monthNumber <= 9) ? ("0" + monthNumber) : String(monthNumber)
~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
now we produce:
error: binary operator '+' cannot be applied to operands of type 'String' and 'Int'
var monthString = (monthNumber <= 9) ? ("0" + monthNumber) : String(monthNumber)
~~~ ^ ~~~~~~~~~~~
note: overloads for '+' exist with these partially matching parameter lists: (Int, Int), (String, String), (UnsafeMutablePointer<Memory>, Int), (UnsafePointer<Memory>, Int)
var monthString = (monthNumber <= 9) ? ("0" + monthNumber) : String(monthNumber)
^
which is the correct diagnostic. While I'm at it, improve the location info for this
binary operator diagnostic to point to the right spot (the operator) and highlight
the LHS/RHS of the operator.
Swift SVN r29774
