Also remove mention of the word “contextual” type from the diagnostic
that rewrites array literals into dictionary literals and scale back
the scope of the diagnostic. This method was catching and
mis-diagnosing too many errors that could better be handled by invalid
conversion diagnostics.
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.
This presents a regression in diagnostic quality that is definitely
worth it not to lie to SILGen about whether a switch is covered or not.
At the same time, disable SIL’s unreachable diagnostic for ‘default’
clauses which would previously cause a warning to be emitted if the
default was proven to be unreachable. This analysis is incomplete
anyways and can be done by Sema in the future if we desire.
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.
Previous versions of Swift accidentally treated lazy properties as
computed properties because of how they were implemented. Now that we
check this correctly, we've broken source compatibility. Downgrade the
error to a warning in this case.
(Arguably we could /allow/ overriding with a stored property. The
original concerns were that you could accidentally end up with extra
storage you didn't need, and that observing accessors would behave
differently based on whether or not the property was overriding. But
there's at least no ambiguity for 'lazy', which can't have observing
accessors today.)
rdar://problem/35870371
Instead, just emit a deprecation warning and suggest switching to Optionals.
The old behavior caused several projects to break, so before we change
the behavior here we need to investigate whether we can mitigate most
of those breaks.
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.
For now these are underscored attributes, i.e. compiler internal attributes:
@_optimize(speed)
@_optimize(size)
@_optimize(none)
Those attributes override the command-line specified optimization mode for a specific function.
The @_optimize(none) attribute is equivalent to the already existing @_semantics("optimize.sil.never") attribute
When testing KeyPathApplication constraints, we would keep going after rejecting a concrete KeyPath application by trying PartialKeyPath and AnyKeyPath, even though that's not what we want, since any key path application expression can type check with an AnyKeyPath. We would then miscompile by building the AST such that we applied the mismatched key path expression directly to the base. We also didn't handle expressions where the base was a subtype of the key path's base type correctly—the conversion means the base can't be written through in this situation, and we hardcoded the concrete-to-existential case instead of handling general conversions. Fix these problems, and add an AST verifier for KeyPathApplicationExprs to help catch problems in the future. Fixes SR-6300 | rdar://problem/35368903.
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.
When printing SIL, we end up printing both @noescape and @autoclosure. It's
not technically wrong (just redundant), so allow it when parsing the SIL
back.
When printing SIL, we end up printing both @noescape and @autoclosure. It's
not technically wrong (just redundant), so allow it when parsing the SIL
back.
SE-0054 specified that the use of implicitly unwrapped optionals was
limited to just a few places, but the implementation at the time did not
completely ban the other uses. This is another attempt to do so, but
it's only on for compilations in Swift 5 mode and later.
For earlier versions, we fall back on the existing implementation.
Fixes: rdar://problem/27707015
Per SE-0054, implicitly unwrapped optional is not a distinct type in the
type system, but rather just the notion that certain Optionals (denoted
by the sigil "!" rather than "?") can be implicitly unwrapped.
This is a first step in the direction of implementing this notion by
emitting a warning if the type is spelled out.
When a particular nominal type or extension thereof declares conformance
to a protocol, check whether that type or extension contains any members
that *nearly* match a defaulted requirement (i.e., a requirement that
is satisfied by something in a protocol extension), but didn’t match
for some reason and weren’t used to satisfy any other requirement of
that protocol. It’s intended to catch subtle mistakes where a default
gets picked instead of the intended member.
This is a generalization of the code we’ve had for @objc optional
requirements for a long time.
Fixes rdar://problem/24714887.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
