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.
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
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
Attach this attribute to VarDecls declared as IUO, and to function decls
that have a result type that is an IUO.
NFC at the moment. Eventually we'll use these to determine where to
implicitly unwrap optional values.
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.
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.
Associated type redeclarations occasionally occur to push around
associated type witness inference. Suppress the warning about redeclarations
that add no requirements (i.e., have neither an inheritance nor a
where clause).
Add TypeChecker::isInsideCompatibleUnavailableDeclaration().
Pass in the call site's AvailableAttr and compare its platform to those
in the enclosing lexical scopes.
Added some basic tests.
The synthesized declarations should inherit the @_versioned attribute
from the type, just like they inherit access control.
Fixes <rdar://problem/34342955>.
As we do with "where" clauses, print the "inheritance" clauses of
protocols and associated type declarations using the requirement
signature of the protocol rather than the "inherited" list.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
This also removes some dead code, where an early assert() ensures that
'strong' is never passed into the function, but then the function later
tries to handle 'strong'.
Finally, use a switch statement for future proofing.
Due to the wanton use of 'if' rather than 'switch', non-observing,
non-get/set ccessors that got marked '@objc' would cause an
assertion. Fix the materializeForSet case from the bug report as well
as the addressor case.
Fixes SR-5025 / rdar://problem/32426538.
Also restore some diagnostics in TypeCheckType that should have
migrated with the attributes. In particular, diagnose cases where
we have @autoclosure with any function type repr with a non-Void
input type.
Resolves SR-5296
When we see two type(aliase)s with the same name in a protocol
hierarchy, make them equal with an implied same-type requirement. This
detects inconstencies in typealiases across different protocols, and
eliminates the need for ad hoc consistency checking. This is a step
toward simplifying away the need for direct-diagnosis operations
involving concrete type mismatches.
While here, warn when we see an associated type with the same as a
typealias from an inherited protocol; in this case, the associated
type is basically useless, because it's going to be equivalent to the
typealias.
Saying "implicitly non-escaping because it was declared @autoclosure"
does not make sense. Since Swift 3, parameters of function type are
non-escaping by default, whether or not they are @autoclosure.
We would also inhibit the fixit for inserting @escaping if the
@autoclosure attribute was present. Again, a holdover from the
Swift 2 days, when @autoclosure implied @noescape and the special
@autoclosure(escaping) attribute was used to define an escaping
autoclosure.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
This is a second revision of the patch -- instead of changing
getEffectiveAccess() to take an extra parameter, this changes
getFormalAccessScope() instead.
Fixes <rdar://problem/32592973>.
