The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
The currying behavior of method references completely breaks in the face of `inout` semantics, even moreso with exclusivity enforcement, but we failed to diagnose these references in Swift 4 and previous versions. Raise a compatibility warning when these references are found in Swift 4 code, or error in Swift 5 and later. Simplify the partial application logic here slightly too now that standalone functions do not allow currying. Addresses rdar://problem/41361334 | SR-8074.
Previously we made sure that inlinable function bodies only
reference @usableFromInline or public declarations, but we
also have to make sure that @usableFromInline declarations
only reference other declarations that are at least as
visible.
Otherwise, you could, for example, define a @usableFromInline
typealias which referenced an internal type, and then
reference the typealias from a @usableFromInline function body.
We weren't checking this before, which would let you define a
public protocol that no public type could conform to.
This is a source-breaking change, so stage it in with a warning.
It becomes an error in -swift-version 5 mode.
In Swift 4, constructors had the same name as properties,
methods and enum cases named `init`. This meant that you
could use constructor syntax to call such a member, which
caused some confusing behavior.
Recently I added a special declname for `init` so that
constructors have unique names distinct from any name you
can spell, and "foo.init" syntax would look for a member
with the special name rather than one named `init`.
Unfortunately people actually had code where they defined
members named `init` and then use them via normal member
lookup syntax, like this:
enum E {
case `init`
}
let e: E = E.init
So to maintain backward compatibility, hack member lookup
to also find members named `init` when looking up the special
declname for constructors.
The workaround is only enabled in Swift 4 and 4.2 mode;
in Swift 5 mode you are expected to write "foo.`init`" to access
non-constructor members named `init`.
Fixes <rdar://problem/38682258>.
Normally we don't gate *warnings* on -swift-version flags, but
SwiftNIO makes use of @_inlineable / @_versioned and wants to
continue building with Swift 4.1 until 4.2 is released.
Fixes <https://bugs.swift.org/browse/SR-7578>,
<rdar://problem/40717640>.
In Swift 3 mode, the canonical private DeclContext should
not look through extensions.
The only way I can reproduce this is with a missing warning
and we don't really care about missing warnings in Swift 3 mode.
However, the next patch in this PR regresses more things so
let's fix it properly.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
* [Diagnostics] Improve accessibility diagnostics for inheritance from generic classes
Fixed misleading warning when message pointed to the type's superclass access level instead of the access level of the type used as a generic parameter of the superclass when inheriting
* updated 'Compatibility' tests (warnings)
* updated the diagnostic's error version
Resolves: SR-7349
Ensure that we use the correct python to run the python based tools.
This also allows these tools to run on Windows which will not
necessarily associate the python script with an interpreter (python).
Note that I said "warnings"; we're going to be more cautious about
rollout and just make this a warning in Swift 5 mode, with /no/
diagnostics in Swift 3 and 4. Users are still free to use `@unknown
default` in these modes, and they'll get a fatal run-time error if
they don't and an unexpected case actually shows up.
rdar://problem/29324688
At one point compiler wouldn't let you use them in matches, so people have
had to use catch-all cases instead. SILGen already handles this because of
@_downgrade_exhaustivity_check, as well as non-exhaustive enums in
Swift 4 mode.
rdar://problem/33246586
- Combine the common logic for editor mode and non-editor mode.
- Do a better job minimizing fix-its.
- If '@unknown' is the only missing case, put `fatalError()` in the
Xcode placeholder, since that's what the compiler would have done.
That is, when matching non-frozen enums at non-top-level positions:
switch (nonFrozenEnum1, nonFrozenEnum2) {
case (.singleKnownCase1, .singleKnownCase2): ...
unknown: ...
}
...it's sufficient to use '@unknown' to match
(.singleKnownCase1, .someFutureCase2)
(.someFutureCase1, .singleKnownCase2)
(.someFutureCase1, .someFutureCase2)
The other half of '@unknown' in Sema. Again, the diagnostics here
could be improved; rather than a generic "switch must be exhaustive",
it could say something about unknown case handling known cases.
One interesting detail here: '@unknown' is only supposed to match
/fully/ missing cases. If a case is /partly/ accounted for, not
handling the rest is still an error, even if an unknown case is
present.
This only works with switches over single enum values, not values that
contain an enum with unknown cases. That's coming in a later commit.
(It was easier to get this part working first.)
The first half of Sema support for '@unknown'. The other part is
handling when the user /does/ write '@unknown', which results in
/other/ things being downgraded to warnings.
The diagnostics here are still pretty minimal; they should explain
what's going on with '@unknown' to someone who hasn't read the Swift 5
release notes.
That hack resulted in already matching argument and parameter to end
up not matching in this case.
Fixes https://bugs.swift.org/browse/SR-7191
and rdar://problem/38798063
If an extension refers to a generic typealias that has yet to resolve to
a fully-sugared type, look through the underlying type.
Fixes rdar://problem/39023438.
Previously, both CountableRange and CountableClosedRange required
their bound types to be Strideable with a Stride type that conforms to
SignedInteger. Those constraints were not present on the generic
typealiases that replaced these structs. Add them back now, which
fixes the GRDB source compatibility regression.
Fixes https://bugs.swift.org/browse/SR-6907 / rdar://problem/29066394.
This function was unable to "look through" an unbound generic typealias to
find the underlying nominal type that was getting extended, which can occur
if we end up performing a name lookup into this context before the extension
itself has been fully-checked.
Also, test that extending DictionaryIndex works.
When extending a type via a generic typealias, where the type parameters of
the underlying nominal type line up precisely with those of the
generic typealias and its specialization of the underlying nominal
type (a so-called "pass-through" typealias in the new code), maintain
type sugar in the extension declaration.
This new type sugar enables inference of type requirements from the
generic typealias, which is both useful by itself (it lets the type
requirements on generic typealiases be meaningful for extensions like
they are elsewhere), and also addresses a source-compatability
regression where an extension of `CountableRange` will now infer the
requirement `Bound: Comparable`.
Fixes SR-6907 / rdar://problem/29066394.
Currently, when we reference a (non-generic) typealias within a
generic context, we would completely lose type sugar for the
typealias, replacing it with the underlying type. Instead, use
BoundNameAliasType for this purpose, which allows us to maintain all
of the type sugar as well as storing complete substitutions for later
use.
Warn in Swift 4 mode and error in Swift 5 mode when switching on a
non-frozen enum without providing a default case.
Note that this is a preliminary implementation, in order to test the
rest of the feature.
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.
They're already not subclassable publicly, so it's okay for the
initializer to not be available to cross-module clients, just like if
it were non-'required'. This allows constructing a class instance
chosen at runtime /within/ the module without having to expose the
existence of the constructor to everybody.
rdar://problem/22845087
Move the existing test into Compatibility/tuple_arguments_4.swift.
Move the Swift 3 test, Compatibility/tuple_arguments.swift, into
Compatibility/tuple_arguments_4.swift.
Add a couple new tests to each file to capture what we do in each
mode.
Overall this doesn't seem like the most satisfying approach for
covering compatibility testing in our standard commit testing, but
it's all we've got at the moment.
Allow functions with type `(()) -> T` to be passed in places where we
expect `() -> T`, but only for -swift-version 4 (for -swift-version 3
this already works due to other horrible things in CSSimplify.cpp).
We need to look at how we can help migrate these cases to
-swift-version 5, but in the meantime, but that is something we can
consider separately.
We inadvertantly allowed a function conversion for Swift 4 that we did
not intend to allow.
This commit adds an extremely narrow fix to continue to allow this for
-swift-verson 4 only.
Fixes rdar://problem/36875195 / https://bugs.swift.org/browse/SR-6837
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.
