When we match a witness to a requirement in a protocol, we do so based
on the Swift name (which is correct). When the requirement is @objc
(because it is in an @objc protocol), also check that the Objective-C
selectors of the witness match those of the requirement.
Fixes the majority of rdar://problem/18383574.
Swift SVN r24829
Parser may stop at some erroneous constructions like stray #else or #endif, in some cases closing brace ‘}’, etc…
continue parsing until we are done.
Swift SVN r24822
- Closures that are comprised of only a single return statement are now considered to be "single expression" closures. (rdar://problem/17550847)
- Unannotated single expression closures with non-void return types can now be used in void contexts. (rdar://problem/17228969)
- Situations where a multi-statement closure's type could not be inferred because of the lack of a return-type annotation are now properly diagnosed. (rdar://problem/17212107)
I also encountered a number of crashers along the way, which should now be fixed.
Swift SVN r24817
They don't work properly, and if we want eager static initialization,
we'll add a Swift feature for it. Fixes rdar://problem/18423731.
Swift SVN r24814
Before:
error: use of module 'Foo' as a type
After:
error: use of undeclared type 'Foo'
note: cannot use module 'Foo' as a type
Improves on rdar://problem/17763309 a little.
Swift SVN r24564
Rather than keeping just a "main class" in every module, track the "main file"
that's responsible for producing the module's entry point. This covers both
main source files and files containing classes marked @UIApplicationMain or
@NSApplicationMain.
This should have no functionality change, but is preparation for the next
commit, where we will preserve some of this information in serialization.
Swift SVN r24529
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
Append "did you mean 'static'?" when hitting the unimplemented class
stored properties diagnostic in a class context.
Provide a fix-it for typing "static final" in a class, which is
redundant.
Swift SVN r24358
The previous patch to allow static class stored properties
inadvertently allowed 'class final' spellings for static
stored properties in classes. This patch only allows 'static'
spellings to create the global storage.
Swift SVN r24323
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
- Make @autoclosure imply @__noescape everywhere, not just in the stdlib.
- Change various noescape diagnostics to refer to "parameters", not "arguments" of the function.
- Teach the noescape diagnostics to notice if the noescape problem is due to an
@autoclosure argument that is implicitly noescape. In this case, produce a helpful note
that indicates that the invalid use of the noescape is due to the autoclosure implying it.
Swift SVN r24222
This is part of rdar://16323038. Because this hasn't been fully design reviewed and
implemented, I'm naming it as __nocapture for now. It is blocking finishing off the
"improved let model" work.
Swift SVN r24079
everything the type attribute does (notably, doesn't work on parameters),
but this includes the infrastructure to apply it in all the sordid places
that need to be touched for type-adjusting declattributes on variables.
Swift SVN r24044
... now that we have an exquisitely shaved yak.
This provides a simple and uniform model for "let" constants: they are always either
immediately initialized in their declaration, or they are initialized dynamically
exactly once before any use.
This is a simple generalization of our current model for initializers, but enables
the use of let constants in more cases in local context, e.g. patterns like this:
let x : SomeThing
if condition {
x = foo()
} else {
x = bar()
}
use(x)
Previously this would have to be declared a "var" for no good reason: the value is
only ever initialized, never actually mutated.
The implementation of this is reasonably straight-forward now that the infrastructure
is in place: Sema treats 'let' constants as "settable" if they lack an initializer
(either in the declaration or in a non-PBD binding). This exposes them as an lvalue
at the AST level. SILGen then lowers these things to an alloc_stack, and DI enforces
the "initialization only" requirement that it already enforces for uninitialized 'let'
properties in structs/classes.
Swift SVN r23916
These changes make the following improvements to how we generate diagnostics for expression typecheck failure:
- Customizing a diagnostic for a specific expression kind is as easy as adding a new method to the FailureDiagnosis class,
and does not require intimate knowledge of the constraint solver’s inner workings.
- As part of this patch, I’ve introduced specialized diagnostics for call, binop, unop, subscript, assignment and inout
expressions, but we can go pretty far with this.
- This also opens up the possibility to customize diagnostics not just for the expression kind, but for the specific types
involved as well.
- For the purpose of presenting accurate type info, partially-specialized subexpressions are individually re-typechecked
free of any contextual types. This allows us to:
- Properly surface subexpression errors.
- Almost completely avoid any type variables in our diagnostics. In cases where they could not be eliminated, we now
substitute in "_".
- More accurately indicate the sources of errors.
- We do a much better job of diagnosing disjunction failures. (So no more nonsensical ‘UInt8’ error messages.)
- We now present reasonable error messages for overload resolution failures, informing the user of partially-matching
parameter lists when possible.
At the very least, these changes address the following bugs:
<rdar://problem/15863738> More information needed in type-checking error messages
<rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
<rdar://problem/16449805> Wrong error for struct-to-protocol downcast
<rdar://problem/16699932> improve type checker diagnostic when passing Double to function taking a Float
<rdar://problem/16707914> fatal error: Can't unwrap Optional.None…Optional.swift, line 75 running Master-Detail Swift app built from template
<rdar://problem/16785829> Inout parameter fixit
<rdar://problem/16900438> We shouldn't leak the internal type placeholder
<rdar://problem/16909379> confusing type check diagnostics
<rdar://problem/16951521> Extra arguments to functions result in an unhelpful error
<rdar://problem/16971025> Two Terrible Diagnostics
<rdar://problem/17007804> $T2 in compiler error string
<rdar://problem/17027483> Terrible diagnostic
<rdar://problem/17083239> Mysterious error using find() with Foundation types
<rdar://problem/17149771> Diagnostic for closure with no inferred return value leaks type variables
<rdar://problem/17212371> Swift poorly-worded error message when overload resolution fails on return type
<rdar://problem/17236976> QoI: Swift error for incorrectly typed parameter is confusing/misleading
<rdar://problem/17304200> Wrong error for non-self-conforming protocols
<rdar://problem/17321369> better error message for inout protocols
<rdar://problem/17539380> Swift error seems wrong
<rdar://problem/17559593> Bogus locationless "treating a forced downcast to 'NSData' as optional will never produce 'nil'" warning
<rdar://problem/17567973> 32-bit error message is really far from the mark: error: missing argument for parameter 'withFont' in call
<rdar://problem/17671058> Wrong error message: "Missing argument for parameter 'completion' in call"
<rdar://problem/17704609> Float is not convertible to UInt8
<rdar://problem/17705424> Poor error reporting for passing Doubles to NSColor: extra argument 'red' in call
<rdar://problem/17743603> Swift compiler gives misleading error message in "NSLayoutConstraint.constraintsWithVisualFormat("x", options: 123, metrics: nil, views: views)"
<rdar://problem/17784167> application of operator to generic type results in odd diagnostic
<rdar://problem/17801696> Awful diagnostic trying to construct an Int when .Int is around
<rdar://problem/17863882> cannot convert the expression's type '()' to type 'Seq'
<rdar://problem/17865869> "has different argument names" diagnostic when parameter defaulted-ness differs
<rdar://problem/17937593> Unclear error message for empty array literal without type context
<rdar://problem/17943023> QoI: compiler displays wrong error when a float is provided to a Int16 parameter in init method
<rdar://problem/17951148> Improve error messages for expressions inside if statements by pre-evaluating outside the 'if'
<rdar://problem/18057815> Unhelpful Swift error message
<rdar://problem/18077468> Incorrect argument label for insertSubview(...)
<rdar://problem/18079213> 'T1' is not identical to 'T2' lacks directionality
<rdar://problem/18086470> Confusing Swift error message: error: 'T' is not convertible to 'MirrorDisposition'
<rdar://problem/18098995> QoI: Unhelpful compiler error when leaving off an & on an inout parameter
<rdar://problem/18104379> Terrible error message
<rdar://problem/18121897> unexpected low-level error on assignment to immutable value through array writeback
<rdar://problem/18123596> unexpected error on self. capture inside class method
<rdar://problem/18152074> QoI: Improve diagnostic for type mismatch in dictionary subscripting
<rdar://problem/18242160> There could be a better error message when using [] instead of [:]
<rdar://problem/18242812> 6A1021a : Type variable leaked
<rdar://problem/18331819> Unclear error message when trying to set an element of an array constant (Swift)
<rdar://problem/18414834> Bad diagnostics example
<rdar://problem/18422468> Calculation of constant value yields unexplainable error
<rdar://problem/18427217> Misleading error message makes debugging difficult
<rdar://problem/18439742> Misleading error: "cannot invoke" mentions completely unrelated types as arguments
<rdar://problem/18535804> Wrong compiler error from swift compiler
<rdar://problem/18567914> Xcode 6.1. GM, Swift, assignment from Int64 to NSNumber. Warning shown as problem with UInt8
<rdar://problem/18784027> Negating Int? Yields Float
<rdar://problem/17691565> attempt to modify a 'let' variable with ++ results in typecheck error about @lvalue Float
<rdar://problem/17164001> "++" on let value could give a better error message
Swift SVN r23782
- We switch to a model where let properties may be "initialized", but never
reassigned. Specifically, immutable properties in structs/classes may have
an init value specified in their declaration (but can then never be reset
in any init implementation) or not (in which case they must be initialized
exactly once on all paths through every init. This makes a lot more sense
for immutability, defines several problems away, and provides a path to
supporting things like (rdar://16181314)
- We now *never* default initialize an immutable property. Formerly
we would default initialize optional let properties to nil, but this
isn't actually useful, and allows an error of omission with let
properties.
This resolves: <rdar://problem/19035287> let properties should only be initializable, not reassignable
and possibly other radars.
Swift SVN r23779
--This line, and those bel that ow, will be ignored--
M test/Parse/optional.swift
M test/ClangModules/Security_test.swift
M test/expr/expressions.swift
M include/swift/AST/DiagnosticsSema.def
M lib/Sema/CSApply.cpp
Swift SVN r23685
There's no implementation-driven reason for these restrictions, and they're confusing users (https://twitter.com/nicklockwood/status/535123830873006081). We may or may not want to spell this ': class' someday, but today we ought to allow what we have.
Swift SVN r23440
It doesn't make sense to try to limit them in most cases, because there may be protocol conformances we don't know about statically in the dynamic program. Relax casts that always succeed or fail to be a warning instead of an error.
Swift SVN r23298
Diagnose cases where the use of @objc will produce Objective-C methods
that end up overriding an Objective-C method in a superclass, when
that override is not properly represented as an override in the Swift
type system. This can happen when the Objective-C methods are produced
by different kinds of entities. For example:
class Super {
@objc var property: Int
}
class Sub : Super {
@objc func setProperty(property: Int) { }
}
In Swift, Sub.setProperty and Super.property are completely
unrelated. However, both produce an Objective-C instance method with
the selector "setProperty:", so we end up with unexpected overriding
behavior. Diagnose this whenever it occurs, regardless of the kind of
@objc entity that produced the Objective-C methods: initializers,
deinitializers, methods, properties, or subscripts.
Implements the rest of the intended functionality of
rdar://problem/18391046, with the caveat that there are two remaining
classes of bugs:
1) Superclasses defined in a module (or imported from a Clang
module) aren't handled properly yet; we might not see those methods.
2) We won't properly detect all of these failures when the methods
are scattered across different source files in the same module.
Swift SVN r23170
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
Before it was done with a big switch statement, which remained a switch until the final code.
Now it's done by getting an integer index for both enums and just doing an integer compare.
This results in a simple compare in the final code.
Note that the == function is only generated for enums without payload. Getting the integer
index of such enums is a cheap operation.
Swift SVN r23129
This included a test that failed on case-sensitive filesystems. Test fixed.
(Aside: Why not just have this fail with "no such module"? Why use a different
error? Because even if "import FOO" picks up a module named 'Foo', there may
actually be a module named 'FOO' on the system (in another folder), and we
should be able to find that. Fixing that is tracked by rdar://problem/18691936.)
rdar://problem/15632996 (again)
Swift SVN r22856
Due to case-insensitive filesystems, "import foundation" can result in the
overlay module for Foundation being loaded. Everything is confused later on
because the (wrong) module name is used in manglings, leading to all sorts
of issues.
This is not the right fix for the problem, because a user really is allowed
to have modules named "foundation" and "FOUNDATION" and "Foundation" coexisting
on their system. To do that we'll want to check the actual case of a
.framework bundle or .swiftmodule file on disk and make sure it matches before
even trying to load the file. But this is a good sanity check anyway.
rdar://problem/15632996
Swift SVN r22818
This commit updates diagnostic reporting for #os() checks that will always pass.
We now indicate whether the reason the check will always pass is because of the
minimum deployment target or is because of an enclosing scope. In the latter
case, we emit a note indicating the location of the enclosing scope.
Swift SVN r22729
We restrict #os(...) to only the guard condition of if statements. We may want
to loosen this restriction in the future (to, e.g., IfExprs) -- but, in general,
we don't want #os() to appear where static analysis cannot easily determine
its effect.
Swift SVN r22720
Make method/property availability contravariant: the available range of an
override must contain the available range of the overriden declaration.
Swift SVN r22682
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
This avoids a pointless copy every time an array literal is written, and will let us retire the horrible "alloc_array" instruction and globs of broken IRGen code. Implements rdar://problem/16386862, and probably fixes a bunch of bugs related to alloc_array brokenness.
Swift SVN r22289
