If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
generic parameter 'T' is not used in function signature
func f8<T> (x: Int) {}
This commit takes Jordan't comments on r28181 into account:
- it produces a shorter error message
- it does not change the compiler_crashers_fixed test and add a new expected error instead
Swift SVN r28194
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
There is no way to infer the generic parameter 'T' if it is not used in function signature
func f8<T> (x: Int) {}
^
Swift SVN r28181
We now introduce a TypeRefinementContext for the fallthrough branch of a require/else
statement that continues until the end of the BraceStmt that contains the RequireStmt. The
body of the else is checked in the context that contains the RequireStmt.
This enables availability checking with early return:
require #available(iOS 8.0, *) else { return }
Swift SVN r28113
Loosen restrictions on where #available() can appear in IfStmt guards and refine the
context for guard StmtConditionElements following an availability check.
This enables #available() to be combined with if let optional binding:
if #available(iOS 8.0, *),
let x = someIOS8API() {
// Do more iOS 8 stuff
}
and
if let x = someIOS7API() where #available(iOS 8.0, *),
let y = someIOS8API() {
// Do more iOS 8 stuff
}
Swift SVN r28096
Change the syntax of availability queries from #available(iOS >= 8.0, OSX >= 10.10, *) to
This change reflects the fact that now that we spell the query '#available()' rather than
'#os()', the specification is about availability of the APIs introduced in a particular OS
release rather than an explicit range of OS versions on which the developer expects the
code to run.
There is a Fix-It to remove '>=' to ease adopting the new syntax.
Swift SVN r28025
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
a list of their elements, instead of abusing TupleExpr/ParenExpr
to hold them.
This is a more correct representation of what is going on in the
code and produces slightly better diagnostics in obscure cases.
However, the real reason to fix this is that the ParenExpr's that
were being formed were not being installed into the "semantic"
view of the collection expr, not getting type checked correctly,
and led to nonsensical ParenExprs. These non-sensical ParenExprs
blocked turning on AST verification of other ones.
With this fixed, we can finally add AST verification that
IdentityExpr's have sensible types.
Swift SVN r27850
Change how MemberRefExpr and DynamicMemberRefExpr calculate their starting locations so
that even if their base expression is implicit, they will use its starting location if
that location is valid rather than falling back to the start of the name of the member.
Without this change, the Fix-It to suggest wrapping a nested member reference (where the
base is an implicit LoadExpr) in 'if #available(...)' would be inserted in the middle of
the expression.
rdar://problem/20662960
Swift SVN r27799
We now produce tailored diagnostics for assignment operators that are passed a non-mutable LHS,
e.g.:
t.swift:14:3: error: cannot pass 'let' value 'x' to mutating binary operator '/='
x /= 19
~ ^
t.swift:13:1: note: change 'let' to 'var' to make it mutable
let x = 42
^~~
var
Swift SVN r27780
- <rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
- <rdar://problem/16927246> provide a fixit to change "let" to "var" if needing to mutate a variable
We now refer to an inout argument as such, e.g.:
t.swift:7:9: error: cannot pass 'let' value 'a' as inout argument
swap(&a, &b)
^
we also produce a note with a fixit to rewrite let->var in trivial cases where mutation is
being assed for, e.g.:
t.swift:3:3: note: change 'let' to 'var' to make it mutable
let a = 42
^~~
var
The note is produced by both Sema and DI.
Swift SVN r27774
We now produce diagnostics like:
- cannot pass 'let' value 'a' to mutating unary operator '++'
- cannot pass get-only property 'b' to mutating unary operator '++'
- cannot pass immutable value of type 'Int64' to mutating unary operator '++'
Swift SVN r27772
To be safe, protocol witnesses need to be as available as their requirements.
Otherwise, the programmer could access an unavailable declaration by upcasting
to the protocol type and accessing the declaration via its requirement.
Prior to this commit, we enforced safety by requiring that the annotated
available range of a requirement must be completely contained within the
annotated available range of the witness.
However, there are cases where this requirement is too restrictive. Suppose
there is some super class Super with an availability-restricted method f():
class Super {
@availability(iOS, introduced=6.0)
void func f() { ... }
}
Further, suppose there is a protocol HasF with unrestricted availability:
protocol HasF {
void func f()
}
and then a limited-availability class Sub extends Super and declares a
conformance to HasF:
@availability(iOS, introduced=8.0)
class Sub: Super, HasF {
}
Sub does conform to HasF: the witness for HasF's f() requirement is Super's f().
But Super's f() is less available (iOS 6 and up) than HasF's f() requires
(all versions) and so--prior to this commit--the compiler would emit
an error.
This error is too conservative. The conforming type, Sub,
is only available on iOS 8.0 and later. And, given an environment of iOS 8.0
and later, the availability of the requirement and the witness is the same, so
the conformance is safe.
This false alarm arises in UIKit, where Super is UIView, HasF
is UIGestureRecognizerDelegate, and f() is gestureRecognizerShouldBegin().
The fix is to change the safety requirement for protocol witnesses:
we now require that the intersection of the availabilities of the conforming
type and the protocol requirement is fully contained in the intersection of the
availabilities of the conforming type and the witness. It does not matter if
the containment does not hold for versions on which the conforming type is not
available.
rdar://problem/20693144
Swift SVN r27712
Update the Fix-It thats suggests adding a #available() check to include the
wildcard query '*', which is now required. We were omitting it before, which
meant that after applying this Fix-It the developer would get a second Fix-It
to add the '*'.
rdar://problem/20601569
Swift SVN r27514
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
Suppress API availability diagnostics about protocol conformances when the
-disable-availability-checking frontend flag is passed. We weren't
checking the flag before, so there was no way to disable this diagnostic.
I've added a test to make sure this flag is honored. We can remove the test when
we remove the flag, which is temporary.
Swift SVN r27439
The post-type-checking error that was here is arguably better QoI, but it is causing ambiguities that break the non-ObjC-compatible build in the stdlib. We shouldn't even attempt these conversions if there's no runtime support to back them up.
Swift SVN r27407
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
Make sure that a witness declaration is at least as available as
the protocol requirement declaration. This is analogous to requiring that an
override is at least as available as the base declaration.
We don’t use the RequirementMatch machinery to mark a candidate as unsafe but
rather let the witness be chosen and then diagnose for potential unavailability.
That is, potential unavailability will not affect the search for a candidate
witness to a requirement. This is less expressive (users cannot write a protocol
that selects an available implementation) but is more predictable.
Swift SVN r27256
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
This is the same as the reverted r27216 except that it does not suggest a FixIt
to make the property lazy.
Swift SVN r27223
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
We can safely support potential unavailability on lazily initialized
properties (and statics), so suggest a Fix-It that adds a lazy attribute when
the property declaration allows for it.
Swift SVN r27216
Remove the suppression of deprecation and potential unavailability diagnostics in
synthesized functions. We still suppress some explicit unavailability diagnostics -- those
in synthesized functions in synthesized functions that are lexically contained in
declarations that are themselves annotated as unavailable. For these cases, the right
solution <rdar://problem/20491640> is to not synthesize the bodies of these functions in
the first place.
rdar://problem/20024980
Swift SVN r27203
In source files that are in script mode, global variable initialization
expressions are eagerly executed. For this reason, disallow @availability
attributes having 'introduced=' on script-mode globals.
I had to rejigger a fair number of potential unavailability tests because they
weren't written with this distinction in mind.
Swift SVN r27137
Synthesize implicit @availability attributes to make sure that a synthesized
materializeForSet accessor is available enough to access the underlying storage and its
getter and setter.
These synthesized attributes could trigger redundant diagnostics when a subclass gives
overriding getters or setters non-contravariant availability. We detect when this
happens and suppress the redundant diagnostics.
This commit also improves availability diagnostics in synthesized code. We now respect
synthesized @availability annotations on containing DeclContexts when determining the
potential OS versions that could be executed at invalid SourceLocations.
Swift SVN r27002
The API review list found it confusing that if #os() and #if os() looked so similar, so
change the availability checking query to be spelled #available:
if #available(iOS >= 9.0, *) {
...
}
Swift SVN r26995
A "switch" can't be empty, so special-case the 'code' implementation for an empty ErrorType to just return zero. It doesn't really matter what the value is since the enum can't be instantiated.
Swift SVN r26992
On platforms that are not explicitly mentioned in the #os() guard, this new '*'
availability check generates a version comparison against the minimum deployment target.
This construct, based on feedback from API review, is designed to ease porting
to new platforms. Because new platforms typically branch from
existing platforms, the wildcard allows an API availability check to do the "right"
thing (executing the guarded branch accessing newer APIs) on the new platform without
requiring a modification to every availability guard in the program.
So, if the programmer writes:
if #os(OSX >= 10.10, *) {
. . .
}
and then ports the code to iOS, the body will execute.
We still do compile-time availability checking with '*', so the compiler will
emit errors for references to potentially unavailable symbols in the body when compiled
for iOS.
We require a '*' clause on all #os() guards to force developers to
"future proof" their availability checks against the introduction of new a platform.
Swift SVN r26988
Provide compiler-synthesized implementations of ErrorType that use the type name as domain and a per-case integer as code. (TBD would be some mapping of the associated data to userInfo in Cocoa.)
Swift SVN r26780
When synthesizing a designated initializer override, we now ensure that the synthesized
initializer has the same availability as the initializer it is overriding.
Swift SVN r26732
We now disregard deprecation warnings if the reference to a deprecated symbol is lexically
contained in a declaration that is itself deprecated on all deployment targets.
Swift SVN r26693
It’s real intent is to check only the generic signature of the DeclContext provided to name lookup, then enclosing contexts. Use it for functions and initializers as well, so we have uniform lookup behavior for entities that can have generic parameters.
A follow-up commit contains some minor, semi-related tweaks along with a pile of updates to the compiler crash testsuite.
Swift SVN r26654
Change availability Fix-It notes to use a DescriptiveDeclKind so that the notes are
more precise in their description of where an availability attribute will be added.
So, for example, the note will now say "add @availability attribute to enclosing class"
instead of "add @availability attribute to enclosing type".
In these Fix-Its, I have special-cased the descriptive kind for PatternBindingDecls to
instead use the description for an associated VarDecl to avoid describing property
declarations as "pattern bindings" to the user.
Swift SVN r26420
is invalid and produces a ParseError, recovery by producing an AST with an ErrorExpr in it
instead of dropping the initializer on the floor. This silences downstream errors about
"must have an initializer" sorts of stuff.
Swift SVN r26405
The commit fixes availability Fix-Its on enum elements to suggest a new availability
attribute on the enum case (which is where attributes live in concrete syntax) rather than
on the enum element (which is where they are attached in the abstract syntax tree).
Swift SVN r26401
Minor tweaks to availability diagnostic text based on feedback from Chris, Ted, and Doug.
This changees "'foo' is only available on OS X version 10.10 or greater" to
"'foo' is only available on OS X 10.10 or newer".
This change also updates the deprecation and obsoleted diagnostics to be consistent with
the new text.
Swift SVN r26344
This commit suppresses errors for references to unavailable symbols inside
implicit functions.
This is a quick hack to fix a hit-listed radar <rdar://problem/20007266> where
the compiler was emitting spurious errors for enums explicitly marked
unavailable in Objective-C and whose nil literal conformance is synthesized by
the importer. These errors could occur when user code made no apparent reference
to the enum in question and instead only referred to an imported class that
itself referred to the enum in a method signature.
We will need to do something systematic about availability and deprecation
diagnostics in synthesized code. In particular, we should make sure that:
(1) we never emit code that references explicitly unavailable symbols;
(2) that the user never gets an error about symbol that they did not explicitly type; and
(3) that errors can dealt with via the appropriate availability check or annotation. I'm
tracking this with radar rdar://problem/20024980.
rdar://problem/20007266
Swift SVN r26251
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
If the placeholder is a typed one, parse its type string into a TypeRepr,
resolve it during typechecking and set it as the type for the associated EditorPlaceholderExpr.
Swift SVN r26215
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
We now suggest up to three Fix-Its for each reference to a potentially
unavailable symbol: one to wrap the reference in an if #os(...) { ... }
guard (if possible), one to add an @availability attribute to an enclosing
property or method (if possible), and one to add an @availability attribute
to an enclosing class/struct/extension, etc. or global function.
The goal here is not to infer the "best" Fix-It but rather to ensure
discoverability of #os() and @availability attributes. We want the user, when
faced with an availability diagnostic, to be aware of the tools in her toolbox
to deal with it.
This is still missing QoI improvements, including Fix-Its to update
existing @availability attributes and more precise wording in diagnostics
(e.g, "initializer" instead of function, "class" instead of "type"). These
improvements will come in later commits.
Swift SVN r26073
a let/var pattern. Now any identifier in one of these is a variable binding,
not sometimes a value references (depending on contextual syntax).
This isn't expected to have a widespread effect on existing real world code:
- No impact on the stdlib.
- It does fix two validation crash tests, but possibly because the original issue is hidden by a different diagnostic path in the compiler.
- This needed two tests to be tweaked to undistribute "let".
On the positive side, this means that "case let x?:" now works properly, woo.
Swift SVN r26000
Make this diagnostic a little nicer in other ways, too:
- Highlight the whole attribute (including the at-sign).
- Don't hardcode the string "objc".
Swift SVN r25999
Resolving signatures of declarations from files other than the primary source
file causes first-pass type checking, including diagnostics for potential
unavailability, to be performed on those declarations. Prior to this commit, the
type refinement context hierarchy was only constructed for the primary file, so
spurious errors were emitted when checking declarations in other files. With
this commit, the availability checker builds the hierarchy for a source file the
first time its hierarchy is queried. We will eventually want to build the
hierarchy more lazily, but that will come later.
Swift SVN r25746
This commit suppresses deprecation warnings for references to deprecated symbols
by climbing the DeclContext hierarchy to determine if the warning location is
inside an implicit function.
This is a quick fix to get rid of spurious warnings for deprecated enums whose
nil literal conformance is synthesized by the importer. These warnings would
occur even when user code made no apparent reference to the enum in question and
instead only referred to an imported class that itself referred to the enum in a
method signature. This quick fix intentionally drops some valid warnings
(for example, for a synthesized call to a deprecated initializer in a super
class). rdar://problem/20024980 tracks adding these special purpose warnings
back.
rdar://problem/20007266
Swift SVN r25720
At Jordan's request, add a test to ensure that we emit an error when a declaration
inside an extension is more available than the extension itself. Also change a
getContextKind() comparison + cast<> to a dyn_cast<>.
Swift SVN r25592
This commit allows @availability attributes on extensions.
Unlike other declarations, extensions can be used without referring to them
by name (they don't have one) in the source. For this reason, when checking
the available version range of a declaration we also need to check to see if it is
immediately contained in an extension and use the extension's availability if
the declaration does not have an explicit @availability attribute itself.
This commit also moves building the primary file type refinement context hierarchy
in performTypeChecking() to before we resolve extensions. Resolving extensions checks for
availability of the extended declaration, so the TRC for the extension must be constructed
before then.
Swift SVN r25589
