The defer body func is only ever fully applied, so SILGen can avoid allocating a closure for it if it's declared as a 'func', making it slightly more efficient at -Onone.
Swift SVN r30638
CSApply). The code is somewhat simpler there, more correct (fixing the FIXME in the
testcase) and doesn't run afoul of CSDiags trying to type check partial AST
subexpressions.
Swift SVN r30425
Otherwise, people subclassing NSView will accidentally call NSView.print
when they're trying to call Swift.print.
rdar://problem/18309853
Swift SVN r30334
avoid emitting this diagnostics. They are always irritating to it because they
are duplicative with whatever the actual type constraint problem is. It also
interferes with there recursive structure of the problem.
Disabling them also allows us to shorten the black list of expr nodes that cannot
be handled in typeCheckIndependentSubExpression.
Swift SVN r30122
... by reimplementing the DiscardAssignmentExpr checker in MiscDiagnostics
instead of being in CSApply (which gets run on partial expression ASTs).
Also, when type checking and salvaging an expression fails, do not generate
structural diagnostics in addition to the type checker diagnostics, they are
just noise.
Swift SVN r29937
Enhance fixItRemove() to be a bit more careful about what whitespace it leaves around: if the thing it is removing has leading and trailing whitespace already, this nukes an extra space to avoid leaving double spaces or incorrectly indented results.
This includes an extra fix for looking off the start of a buffer, which extractText doesn't and can't handle.
This fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29449
if the thing it is removing has leading and trailing whitespace already, this nukes
an extra space to avoid leaving double spaces or incorrectly indented results. This
fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29419
getTypeOfIndependentSubExpression() might replace some values in the
given expression with OpaqueValueExprs, but if the type checker
decided to insert the corresponding OpenExistentialExpr at the top
level, the AST would now be in an inconsistent state, since
getTypeOfIndependentSubExpression() does not return a new expression
to the caller.
Ideally we would separate out type checking from expression rewriting
so that the latter is only performed when we know the expression
type checks, but that is a bigger project. For now, erase open
existentials after re-typechecking a sub-expression.
Fixes <rdar://problem/20598568>.
Swift SVN r29400
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
We no do not require "self." for closures capturing self in static/class methods.
While we do actually capture the metatype more than we should (rdar://21030087),
this doesn't matter to the developer, since this capture cannot cause a cycle
in the reference graph that they should have to reason about.
Swift SVN r28804
Allow API providers to use escaped characters in the messages of @available()
attributes. For example, for a reference to a declaration annotated with:
@available(*, unavailable, message="use print(\"\")")
public func println() {
...
}
the message displayed to the user will be:
'println() is unavailable: use print("")'.
This also supports unicode escapes (e.g. \u{1F43C}).
A complication is that AvailableAttrs imported from clang already have their
messages unescaped, so this patch keeps track of whether an availability
attribute came from clang and, if so, does not unescape the message again when
emitting the diagnostic. We could avoid this extra book-keeping by immediately
unescaping Swift messages during parsing, keeping them in an unescaped
canonical form, and then escaping them in ASTPrinter when we print the
attributes. rdar://problem/20985357 tracks keeping AvailableAttrs messages in
a canonical form.
rdar://problem/20789407
Swift SVN r28658
If a 'var' pattern binding contains multiple vardecls and some are mutated
but others aren't, don't warn about the non-mutated ones as being potential
candidates for 'let's since there is no great way to rewrite the code to
silence the warning.
Swift SVN r28629
This reverts revision r28480, after mailing list discussion it is
agreed that this is a bad idea.
Note that a test had to be updated adding a new expected warning.
Swift SVN r28515
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
While we don't support classes that close over values in the outer
scope just yet, make the analysis handle it, to avoid emitting
spurious diagnostics about unused values.
For example, this would formerly daignose that 'x' was both unused
and that the closure was invalid:
func brigand() {
let x = 0
class Sword {
func attack() {
print(x)
}
}
}
Swift SVN r28480
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
within accessors.
Improves source fidelity and fixes problems with error handling
(because TryExpr and ForceTryExpr are IdentityExprs).
Swift SVN r28298
This fixes <rdar://problem/20494437> SILGen crash handling default arguments
again, and includes a fix for MiscDiagnostics to look through the generated
TupleShuffleExprs in @noescape processing (which tripped up XCTest).
This fixes <rdar://problem/16860940> QoI: Strict keyword arguments loses type sugar in calls
where we'd lose some type sugar.
This fixes sanity in the ASTs: ScalarToTupleExpr now always has consistent
types between its argument and result, so we can turn on AST Verification of it.
Swift SVN r27827
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
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
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
Suppress diagnostics about references to unavailable declarations when all
of the following conditions are met:
(1) the reference is in synthesized code;
(2) the reference is in a synthesized method; and
(3) the reference is inside a declaration marked as unavailable.
This, combined with prior work to infer availability annotations for synthesized
methods should eliminate the spurious diagnostics we have seen (e.g.,
rdar://problem/20154926) for references to unavailable types without the hammer
of suppressing all references to unavailable declarations in synthesized
functions. The right thing to do here is to not synthesize the bodies of these
functions in the first place. I've filed <rdar://problem/20491640> to track
this.
We will continue to emit an error for references to unavailable declarations
in non-implicit code, even if the reference is inside a declaration marked
unavailable.
Swift SVN r27197
A common operation for availability checking is determining whether some
lexically enclosing declaration matches a condition. This commit factors
out that logic. NFC.
Swift SVN r27181
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
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
This flag enables checking of availability (deprecation, explicit unavailability,
and potential unavailability) in synthesized functions. The flag will go away once this
checking is fully staged in.
Swift SVN r26624
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
