To make generic signature builder more robust it's imperative to
eliminate possibility of out-of-order typealias substitution.
These changes try to make it so potential archetypes could only be
constructed with associated types by doing early concrete type (typealias)
subsitution while trying to resolve equivalence class.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
This restriction came from wanting to make resilient and non-resilient
code follow the same rules whenever possible, but after thinking about
it a bit more we realized there was no reason why you /wouldn't/ just
mark your structs @_fixed_layout in non-resilient libraries anyway.
Since that (currently?) doesn't affect what you can do with the struct
across module boundaries, and since the layout of the struct is
available anyway in a non-resilient library, there's no real downside,
which means it's a meaningless restriction.
The same logic doesn't /quite/ apply to classes, since classes are
normally much more flexible than structs. (For example, you could add
a stored property to a class without recompiling clients, as long as
no initializers are inlined.) But it's close enough that we don't want
to put in the restriction at this time.
All of this is about attributes that haven't been finalized yet anyway
(hence the leading underscore), but it's still useful information.
rdar://problem/37408668
There are a number of things that can only be written within the main
type definition (e.g., required initializers, stored properties),
making it far more likely that we'll get false positives from the
newly-introduced "near-miss" warnings for protocol
conformances. Moreover, sometimes a number of protocol conformances
are placed on the main type definition, increasing the potential for
false positives.
Suppress near-miss warnings for potential candidates when the protocol
conformance is stated on the main type definition itself. Therefore,
we only perform near-miss checking of non-@objc requirements when the
conformance itself was declared on an extension, which is roughly the
development style that near-miss warnings favor.
Fixes rdar://problem/37283860.
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.
Typealiases in protocol extensions can be used to satisfy
associated type requirements. However, when they don’t meet all
of the requirements placed on the associated type, fall back to
the normal inference path rather than failing outright.
Fixes SR-6609 / rdar://problem/36038033.
There was a path through associated type inference where we would end
up recording a type witness that contained an error, but for which we
had not reported that error, which would lead to downstream
crashes. Make sure that we reject such inferences.
And because it triggers once we fix this issue... make sure break
recursion when trying to resolve type witnesses lazily.
Fixes the crash in SR-6609 / rdar://problem/36038033, but we're still
failing to infer in those cases.
This is technically a source break, but the @_fixed_layout attribute
is not official yet. If anyone really cares, we can make this
conditional on -swift-version 5 later, but I'd rather not.
This change is necessary so that we can give property initializers
non-public linkage. Currently they are public, because they can be
referenced from inlinable initializers.
Now that property initializers inside a @_fixed_layout type can
only reference public symbols, they no longer have to be public,
but making that change requires a bit more work.
Rather than error for overloading by the kind of optional (T? vs. T!)
for inout parameters, just emit a warning for now and continue
compiling.
We'll need to turn this back into an error when we remove IUOs from
the type system.
We translate IUOs to Optionals when generating signatures, but were
failing to look through inout in the process, so we were allowing
functions to be overloaded by Optional vs. IUO when the parameter was
inout.
Fixes https://bugs.swift.org/browse/SR-6685 / rdar://problem/36255630.
Introduce an ugly hack where a typealias in a protocol extension that
has the name `_Default_Foo` can be found by associated type inference for
an associated type named `Foo`, respecting the constrains of the protocol
extension in which that typealias resides.
When a protocol closes off an associated type by tying it to a concrete
type (e.g., via a same-type constraint), allow associated type inference
to use that information to infer the associated type rather than
requiring the user to restate the obvious.
Fixes SR-6640.
During associated type inference, also look for default associated type
witnesses from overridden associated types, so that one need not
redeclare default associated types at every level in a protocol hierarchy.
Fix a silly error where we were returning the interface type of a type
declaration rather than the *declared* interface type, which meant we were
getting a metatype where we shouldn't.
Fixes rdar://problem/36003312.
The Swift class model does not support overriding declarations where either
the overridden declaration or the overriding declaration are in an extension.
However, the Objective-C class model does, so marking the declaration as
@objc (when possible) will work around the limitation.
Customize the "cannot override declaration in extension" diagnostic to
suggest adding @objc to the overridden declaration in cases where
@objc is permitted. Fixes SR-6512 / rdar://problem/35787914.
Move associated type inference into its own class, to make this
code easier to understand/maintain/improve. Minor diagnostics changes
because we're properly passing uninference associated type declarations
to the "group" checker.
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>.
There is nothing specifically wrong with uttering a same-type
constraint in a where clause where both sides are concrete
types. Downgrade this to a warning; we'll check that the concrete
types match (of course), and such a well-formed constraint will simply
be canonicalized away.
This aids the migration of IndexDistance from an associated type to
Int.
Within the where clause of (e.g.) an extension, unqualified name lookup is
permitted to find associated types. Extend this to also include finding
typealiases declared within the protocol itself.
This is service of the IndexDistance change (SE-0191), and
fixes rdar://problem/35490504.
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
Now that struct initializers "just" fall into the delegating case when
they're made inlinable, the only interesting case is class
initializers, which can be checked in a more direct way than what we
were doing before.
(and when the struct in question is non-fixed-layout, which was
already implemented)
This ensures that these initializers are never fieldwise in Swift 5
mode, which makes it safe for library authors to add new fields.
In Swift 4, properties declared with a sugared Optional type,
like Int?, have a default value of nil. This can be observed
in two ways:
- Classes and structs get an implicit no-argument initializer
- Designated initializers don't have to initialize this property
Note that this did not apply in general to properties where
the type was spelled explicitly as Optional<Int>, etc, mostly
because of implementation restrictions -- when we check if a
type has implicit initializers, we have not realized types for
all stored property members yet, and doing so is not really
possible without the iterative decl checker.
However, in some cases, we *did* perform default initialization
for Optional<Int>, because of some code duplication and
divergent code paths.
A recent refactoring cleaned up some of the mess in this area,
but accidentally broke source compatibility with code that
relied on the broken Optional<Int> case.
Fix this by simulating the old behavior in -swift-version 4,
and preserving the more correct behavior in -swift-version 5.
Fixes <rdar://problem/35319847>.
We allow definitions like this:
struct G<T> {}
typealias A = G
As a shorthand for
typealias A<T> = G<T>
A typealias like this cannot satisfy an associated type requirement
for the same reason that a generic typealias cannot satisfy an
associated type requirement, which was already handled.
Previously this would crash in the type checker or in IRGen.
This fixes a weird regression in a fixed compiler crasher from the
next patch.
Within the compiler, we use the term "layout constraint" for any
constraint that affects the layout of a type parameter that has that
constraint. However, the only user-visible constraint is "AnyObject",
and calling that a layout constraint is confusing. Drop the term
"layout" from diagnostics.
Fixes rdar://problem/35295372.
Pavel Yaskevich
Saleem Abdulrasool
Jordan Rose
Erik Eckstein
Doug Gregor
gregomni
Mark Lacey
Bob Wilson
Slava Pestov
Graydon Hoare
Arnold Schwaighofer
swift-ci
Slava Pestov
Hamish