This change permits the use of unavailable types in unavailable signatures.
It affects only usage of `available(*, unavailable)`.
This fixes a compilation error in swift-corelibs-foundation/Foundation/
URLSession/URLSessionConfiguration.swift where an unavailable property
was typed by an unavailable type.
This change permits the use of unavailable types in unavailable signatures.
It affects only usage of `available(*, unavailable)`.
This fixes a compilation error in swift-corelibs-foundation/Foundation/
URLSession/URLSessionConfiguration.swift where an unavailable property
was typed by an unavailable type.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
This is still useful for the feature where deprecated declarations are
allowed to be used within a context that's marked deprecated. There's
probably a better balance to be found here, because marking the
extension deprecated still does not mark all the members deprecated,
but for now it still has an effect, and we shouldn't produce a warning
for legitimately making use of that effect.
The warning was added in f21d9f332, mostly as an opportunity "fix".
https://bugs.swift.org/browse/SR-7577
This handles the case where one accessor is /unavailable/ but not the
other. This is rarer than deprecation (handled in b0e12f4c), but could
still happen.
Finishes rdar://problem/18633725 / SR-7201.
This handles the case where just one accessor is deprecated but not
the other, which does come up sometimes in Apple's frameworks.
rdar://problem/18633725
Previously, we treated this as an attempt to widen the availability
of a member beyond its context, but it's really a different axis of
availability.
Also, warn about using @available on extensions without an OS, which
we just completely ignore right now.
rdar://problem/32632327
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
It is currently impossible to declare a protocol as unavailable and
still ship valid Swift code because while typechecking protocol Self,
we attempt to do an accessibility check on its generic signature and
find that, surprise surprise, the protocol is unavailable. Rather than
plumb another parameter through Sema, this patch piggybacks on existing
behavior of AllowPotentiallyUnavailableProtocol to disable the check
for protocol self.
* [Fixit] Add a fixit for converting non-trailing closures to trailing closures.
* [test] Update test to reflect the added note about converting to trailing closures.
This can be used as QoI for things like 'NSASCIIStringEncoding', which
is going to canonically be `String.Encoding.ascii` if/when SE-0086 is
accepted.
We can't actually handle this in NS_SWIFT_NAME (that is, we can't
/import/ something onto a nested type), but that's okay: we already
have stricter limitations on NS_SWIFT_NAME enforced by Clang.
rdar://problem/26352374
We were failing to create an unavailable TypeAlias for the old name
in the case the renamed type was generic, leading to poor diagnostics.
Also, Sema resolves generic TypeAliases very early, while building
a Type from a TypeRepr -- this means the unavailable/deprecated
check runs too late to catch generic TypeAlises.
Add a hack where we preserve a reference to the original TypeAliasDecl
by way of constructing a SubstitutedType which desugars to the
replacement type, rather than resolving the replacement type
directly, so that the availability check can pick it up.
A better fix for this would be to introduce a BoundGenericAliasType
sugared type, but that's a bigger change that can come later.
Fixes <rdar://problem/26206263>.
...or renaming to operators, unless we're sure the original thing was
an operator expression. There are just a lot of ways this can be
screwed up.
(Some cases of this can certainly be implemented. I may file a
StarterBug later.)
This is the second half of the previous commit. The most common case
of this will be due to the new rules for imported Objective-C API,
but it will also catch things like "I forgot to make the first
parameter not have an argument label".
We don't want to show the funny "getter:Foo.bar(self:)" syntax to
developers, so whenever possible be a little more explicit.
'foo' has been replaced by 'X.newFoo'
'bar(x:)' has been replaced by property 'X.bar'
'baz(x:y:)' has been replaced by instance method 'X.baz(y:)'
(We do run up against the limitation of a string -- this diagnostic
does not do any lookup to find out if the resulting decl actually exists.)
Example:
@available(*, unavailable, renamed: "setter:CGRect.diagonal(self:_:)")
func scale(_ rect: inout CGRect, toDiagonalLength length: CGFloat)
(My examples are getting more and more contrived, but there you go.)
This is pretty much the same as the getter handling, except that we also
want to strip off the '&' at the call site.
While I'm at it, prefer deleting trailing commas and space to leading
commas and space when removing an argument. That's a little more
aesthetically pleasing. We still have to delete a preceding comma if
it's the last argument that's being removed.
Example:
@available(*, unavailable, renamed: "getter:UIColor.CIColor(self:)")
func convertToCIColor(_ color: UIColor) -> CIColor
This syntax looks weird, but it's the same as what's used by
NS_SWIFT_NAME. I intend to improve the diagnostic text once I have
all the fix-its working.
Next up: setters!
Example:
@available(*, unavailable, renamed: "Sequence.enumerated(self:)")
func enumerate<Seq: SequenceType>(_ sequence: Seq) ->
EnumerateSequence<Seq>
This will allow us to reuse this logic to suggest fixes for APIs
turned into members by NS_SWIFT_NAME.
It should have the same form as the argument to NS_SWIFT_NAME
in Objective-C, except that it permits operators and (currently)
disallows instance members and properties. We do get to share the
same parsing code, at least.
This actually caught an error in the Foundation overlay!
Groundwork for SR-1008.
