Generic parameters can become sources of metadata types and
conformances. To access them the layout needs to be available to IRGen.
rdar://37086144
SR-6879
This partially reverts commit 8685ee01a1.
The tests are still in place, but the code change is no longer necessary
now that IUOs are removed from the type system.
Fixes: rdar://problem/37013789
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.
Allow passing Optional<T> as inout where
ImplicitlyUnwrappedOptional<T> is expected, and vice-versa.
Swift 4.1 added a warning that overloading inouts by kind of optional
was deprecated and would be removed, but we didn't actually allow
people to remove an overload and pass arguments of the other kind of
optional to the remaining function.
Fixes rdar://problem/36913150
The subscript_expr typechecker path is different than extension deceleration one - in rdar://problem/36704036, When doing emitVirtualMethodValue in IRGen we can miss the correct offset because we have a bad ClassDecl, The ClassDecl is junk / null
This PR makes said subscript_expr -> call_expr path Behave correctly by request the class layout
Fixes a crash for SourceEntityWalker which assumed that a non-implicit TupleExpr has source locations for its name elements.
Fixes SR-6517, rdar://35830880
When binding an optional value, or function that returns an optional
value, if that value was produced from a decl that was declared an
IUO, create a disjunction.
After solving, make use of the disjunction choices in rewriting
expressions to force optionals where needed.
This is disabled for now, as it results in a source compatibility
issue without associated changes that actually start generating
Optional<T> in place of ImplicitlyUnwrappedOptional<T>. It's
complicated, but basically having two '??' (one returning T, one
returning T?) and creating a disjunction where the first (favored)
choice is ImplicitlyUnwrappedOptional<T> and second is T results in
our selecting the wrong '??' in some cases.
A default argument generator must not return a @noescape function type.
Returning a @noescape function is nonsense. That means the function escapes.
* Assert that we don't return @noescape function types
* Fix for throwing default arguments
* Add more test cases
* Adapt to mangling changes
Part of:
SR-5441
rdar://36116691
Replace ImplicitlyUnwrappedCoercionResult with the more general
ImplicitlyUnwrappedValue.
Add ImplicitlyUnwrappedDisjunctionChoice as a marker that indicates
that we've already created a disjunction from an
ImplicitlyUnwrappedValue, in order to avoid infinite recursion during
binding.
Also add support to buildDisjunctionForImplicitlyUnwrappedOptional for
functions returning optionals.
NFC.
For casts like 'x as T!' or 'x as! T!', generate a disjunction that
attempts to bind both the optional and non-optional T, preferring the
optional branch of the disjunction.
Note that this should effectively be NFC at the moment because we're
still generating the IUO type for T! rather than a plain optional, so
we first attempt the IUO type (as opposed to an Optional<T>) which
goes through existing logic that handles the IUOs as part of the type
system.
The new rewriting logic will actually do something once we switch over
to generating Optional<T> when T! is uttered.
Add a new OverloadChoiceKind for decls that are either IUO-typed, or
function-typed meaning that the function result type is IUO-typed.
Not currently used, so NFC.
Constructing a keypath expression that references a class member
needs to validate all other members of the class (or a protocol,
but I couldn't reproduce a crash with that case -- added a test
anyway).
Fixes <rdar://problem/36083061>.
This is a corner case but would previously lead to a compiler crash
or miscompile.
Fixes <rdar://problem/21991470>, <https://bugs.swift.org/browse/SR-5022>.
Early on in the development of conditional conformances, we put in a bunch
of assertions for code that uses `conformsToProtocol()` but wasn't handling
conditional conformances. Now, `conformsToProtocol()` handles conditional
conformances by default, and these assertions are tripping up code
that would work.
Remove the assertions and add test cases that used to trip up the
assertions (but now work).
These purportedly mark that we should stop attempting fixes for a given
constraint, but in fact the only code creating these is clearly
unreachable so these serve no purpose.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Fix problem related to Swift 3 mode (with assertions),
since Swift 3 mode allows passing arguments with extra parens
to parameters which don't expect them, it should be supported
by "deep equality" types e.g. Optional<T>:
```swift
func foo(_: (() -> Void)?) {}
func bar() -> ((()) -> Void)? { return nil }
foo(bar) // This expression should compile in Swift 3 mode
```
Resolves: rdar://problem/35198459
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
