This adds special tuned diagnostics to handle the case when someone attempts to index
a string with an integer value, which is pretty common to do for people new to Swift.o
That said, this only handles one special case, if there are other cases that are
common, I'd love to hear about them. Subscripts are already handled with a different
approach, I'm not sure which is better, but I added a testcase for both of them.
Warns of deprecation, checks all the appropriate bits to see if we can
do an automatic fix, and generates fix-its if that is valid.
Also adds a note if the loop looks like it ought to be a simple
for-each, but really isn’t because the loop var is modified inside the
loop.
If you use a color literal without first having imported AppKit or
UIKit, the diagnostic is poor. Instead, recommend importing one of those
two modules as appropriate.
Given that the fix for this problem is to insert parentheses, and that we're barfing
in name lookup, we don't have enough information to produce a good fixit here:
in this case, we know where to put the ( in, but we don't know where to put in
the ). Handle this by pointing the caret right to the location of the ( and
make the diagnostic a lot better. This is much less common than the binary operator
case anyway.
This is a frequently reported and surprising issue where lack of whitespace leads to
rejecting common code like "X*-4". Fix this by diagnosing it specifically as a lack
of whitespace problem, including a fixit to insert the missing whitespace (to transform
it into "X * -4". This even handles the cases where there are multiple valid (single)
splits possible by emitting a series of notes.
"use of unresolved operator" when it is talking about one. Add some
testcases to exercise this and show situations where our operator
diagnostics lack greatness.
mode (take 2)
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
When generating constraints for an iterated sequence of type T, emit
T convertible to $T1
$T1 conforms to SequenceType
instead of
T convertible to SequenceType
This ensures that an untyped placeholder in for-each sequence position
doesn't get inferred to have type SequenceType. (The conversion is still
necessary because the sequence may have IUO type.) The new constraint
system precipitates changes in CSSimplify and CSDiag, and ends up fixing
18741539 along the way.
(NOTE: There is a small regression in diagnosis of issues like the
following:
class C {}
class D: C {}
func f(a: [C]!) { for _: D in a {} }
It complains that [C]! doesn't conform to SequenceType when it should be
complaining that C is not convertible to D.)
<rdar://problem/21167372>
(Originally Swift SVN r31481)
It is a somewhat common case where folks are accidentally referring to an
instance member with the Type as the base. This forms a curried member,
which then produced head scratching error messages downstream.
Now that the prep work has gone in, the first part of this is now
straight-forward to fix: simply check for this case and diagnose it
with a custom error, which makes it more clear what the mistake was.
The other half of this problem (tracked by 22108559) affects cases where
the method you're calling takes a single argument. This isn't fixed
yet, but I'm adding a testcase for it anyway.
When we see an unused variable in a simple-enough "if/let" (also guard and
while of course), fixit it into a comparison against nil instead of replacing
the name of the variable with "_". Also special case initialization with an
as? expression, since we can transform that into an "is" boolean test.
This improves the error message when attempting an array to UnsafeMutablePointer
conversion but where the element type of the array is incorrect or where the array itself
is immutable.
As a bonus fix, this dramatically improves the diagnostic when you pass "&array" to
a function that takes an UnsafePointer. We decided to not require & in this case, so
we can just provide a nice fixit to rip it off when this common error happens.
This also rearranges the logic for diagnosing faulty ApplyExprs to group the logic
for a single candidate together in one place. Nothing really earth shattering here,
just yak shaving.
If the returned expression has the same indentation as the "return"
keyword, warn. This warning already existed but wasn't happening
for single-expression closures. Move emission of the warning from Sema
to Parse.
<rdar://problem/16798323>
Put in some rudimentary logic for finding circular references within
the iterative type checker and diagnosing those cycles. The
"rudimentary" part is because we're performing linear searches within
a stack rather than keeping a proper dependency graph, which is
inefficient and could display longer cycles than are actually
present. Additionally, the diagnostic is not specialized to the actual
query, so we get a generic "circular reference" diagnostic. OTOH, we
show all of the declarations involved in the cycle, which at least
lets the user figure out where the cycle occurred.
Enable the iterative type checker for resolving the type of a global
typealiases.
Swift SVN r32572
for: func blah(x: @convention(c) Int throws -> Int) { }
we'd previously complain:
error: @convention(c) type is not representable in Objective-C
now we produce:
error: 'Int throws -> Int' is not representable in Objective-C, so it cannot be used with '@convention(c)'
Swift SVN r32007
Before:
error: cannot import module being compiled
After:
warning: file 'foo.swift' is part of module 'Foo'; ignoring import
rdar://problem/22635888
Swift SVN r31995
For cases where the Clang importer provides a defaulted argument,
e.g., "[]" for option sets and "nil" for optionals, remove the
corresponding arguments at any call sites that simply specify "[]" or
"nil". Such arguments are basically noise, and tend to harm
readability when there are low-content argument labels like "with:" or
"for".
Some examples from Lister:
self.updateUserActivity(AppConfiguration.UserActivity.watch,
userInfo: userInfo, webpageURL: nil)
becomes
self.updateUserActivity(AppConfiguration.UserActivity.watch,
userInfo: userInfo)
and
contentView.hitTest(tapLocation, with: nil)
becomes
contentView.hitTest(tapLocation)
and
document.closeWithCompletionHandler(nil)
becomes simply
document.close()
and a whole pile of optional "completion handler" arguments go away.
Swift SVN r31978
call expression onto a callee when it was a binary expression. Doing this
requires improving the diagnostics for when the contextual result type is
incompatible with all candidates, but that is general goodness all around.
This fixes:
<rdar://problem/22333090> QoI: Propagate contextual information in a call to operands
and improves a number of diagnostics where the problem is that an operator
is used in a context that expects a type that it cannot produce.
Swift SVN r31891
of providing contextual diagnostics (e.g. producing the warning in
Constraints/dynamic_lookup.swift). This drops a specific diagnostic about
force casting the result of as! which was added in the Swift 1.2 timeframe
to explain the change in cast semantics. Now that as! has been around for
a long time, it is more confusing than helpful.
Swift SVN r31887
- Enhance the branch new argument label overload diagnostic to just
print the argument labels that are the problem, instead of printing
the types inferred at the argument context. This can lead to confusion
particularly when an argument label is missing. For example before:
error: argument labels '(Int)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
after:
error: argument labels '(_:)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
Second, fix <rdar://problem/22451001> QoI: incorrect diagnostic when argument to print has the wrong type
by specifically diagnosing the problem when you pass in an argument to a nullary function. Before:
error: cannot convert value of type 'Int' to expected argument type '()'
after:
error: argument passed to call that takes no arguments
print(r22451001(5))
^
Swift SVN r31795
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
In the common case where someone doesn't care about the argument
list to a closure, we now generate a tailored error message with a
fixit to introduce the necessary "_,_ in " nonsense at the start
of the closure. IMO ideally we wouldn't require this, but until we
fix that type checker issue, we should at least give people the
obvious fix.
Swift SVN r31720
expr diagnosis stuff, giving us much better diagnostics on the cases in
expr/closure/closures.swift. This is part #2 of resolving
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31717
specifies some # of arguments but the closureexpr itself disagrees. This is
step #1 to resolving
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31715
This includes a few changes:
- Enhance diagnoseGeneralConversionFailure to not ignore constraints that are fully solved by
CSDiags' heuristics.
- Enhance dictionary/array literals diagnostics to handle non-compliance to their literal
protocols with a specific and custom error message.
- Add specific QoI for turning accidental use of array literals in dictionary context into
the right dictionary syntax (with a fixit).
Swift SVN r31696
member lookup for subscript instead of digging already-looked-up candidates
out of the constraint system. This allows us to produce more specific
diagnostics in failure cases and keeps subscripts inline with other decls
being looked up.
Swift SVN r31586
