This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
Treat non-optional generic parameters as being more specialized than
optional generic parameters, and penalize any solutions that involve
generic arguments that are themselves Optional.
By doing these things, we can remove the special-cased code for the
two overloads of '??' in the stdlib, instead treating the (T?, T)
overload as better than the (T?, T?) overload except where a user
actually passes an optionally-typed value as the second parameter.
Fixes: rdar://problem/19748710
These warnings are turning out to be pretty noisy for code that
declares IUOs (e.g. for @IBOutlets) and then passes them to
Objective-C APIs with parameters declared as _Nonnull id.
Since we bridge non-nil values successfully in most cases, and
previuosly written and correctly executing code is either not seeing
nil values passed in or are handling the nil (which is bridged as
NSNull), it seems like a nuisance to warn about these for existing
Swift versions.
We'll conditionalize the warning, and then users can deal with these
when moving to the new language version.
Fixes: rdar://problem/39886178
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
We previously penalized bindings to Any, and that resulted in
inappropriately rejecting solutions where we bind a decl that is
explicitly typed Any. That penalty was removed in
170dc8acd7, but that has led to a variety
of source compatibility issues.
So now, we'll reintroduce a penalty for Any-typed things, but instead of
penalizing bindings (which happen both because of explicitly-typed
values in the source, and implicitly due to attempting various types for
a particular type variable), penalize casts, which are always present in
some form in the source.
Thanks go to John for the suggestion.
Fixes
SR-3817 (aka rdar://problem/30311052)
SR-3786 (aka rdar://problem/30268529)
rdar://problem/29907555
Revert 7c665c105b because it results in a
much worse source compatibility regression than the one it was intended
to fix.
The problem is that it results in force-unwrapping IUOs, which can lead
to cases where we prefer type-checking solutions that choose methods
over properties where we used to choose properties. So for example a
collection literal like [x] will result in a collection with a method
named 'x' in it rather than a property named 'x'.
I'll be looking at other solutions which fix both the original
compatibility regression as well as retain the behavior in the new test
added here.
Fixes SR-3715 and rdar://problem/30176166.
Commit 170dc8acd7 removed a penalty that
we used to have for conversions to Any. In some unusual circumstances
not having that penalty can result in new amiguities where we should
have nothing ambiguous about an expression according to our type rules.
This change attempts to ensure that we make that less likely or
impossible by not allowing direct conversions from IUOs to Any (instead
forcing these to first be force-unchecked, leading to more expensive
solutions). We never should have allowed these conversions anyway,
independent of removing the penalty for conversions to Any.
This change is intentionally very narrow to avoid further potential
source breakage.
Fixes rdar://problem/29907555.
We currently have an element in the solution score related to whether we
had a binding or equality constraint involving Any.
Doing this yields some strange results, e.g. if overload resolution
results in a property declared as Any we end up discarding that solution
in favor of solutions that involve other overloads that are not declared
as Any but are also not actually better solutions (e.g. overloads that
are declared as function types).
We really want to retain both solutions in this case and allow the
ranking step of the solver to decide on the better choice.
Fixes rdar://problem/29374163, rdar://problem/29691909.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Fix construction and simplication of constructor member locators, so
that locators involving constructor members can be simplified during
diagnosis.
<rdar://problem/21427130> Swift can't discriminate on arity of function parameters
Swift SVN r30932
Take expression depth and preorder traversal index into account when
deciding which unresolved overload to complain about, rather than giving
up if there are two exprs with the same number of overloads. Don't
consider solutions with fixes when emitting ambiguous-system
diagnostics.
Swift SVN r30931
"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
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
We only want to apply the "favored constraint" optimization to symmetric binary operators. This helps prevent the pool of favored constraints from growing so large that it becomes ineffective. (rdar://problem/18008088)
Swift SVN r21184
The determination of “favored” constraints for binary expressions was comparing the second argument to the first parameter to decide if the constraint is favored. Coupled with implicit bridging conversions through NSNumber, this meant that “1.0/10” would become Int when Foundation was imported, and hilarity ensued.
Fix the heuristic for favored constraints, tidy up this code a bit, and add ==(NSString, NSString) to cope with the ambiguity this creates.
Swift SVN r21154
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
Introduces very basic support for diagnosing ambiguous expressions,
where the source of the ambiguity is a reference to an overloaded
name. Simple example:
t.swift:4:1: error: ambiguous use of 'f0'
f0(1, 2)
^
t.swift:1:6: note: found this candidate
func f0(i : Int, d : Double) {}
^
t.swift:2:6: note: found this candidate
func f0(d : Double, i : Int) {}
^
There's a lot of work needed to make this cleaner, but perhaps it will
ease the pain of developing the library <rdar://problem/14277889>.
Swift SVN r6195
