Not quite there yet, because of various problems in ArchetypeBuilder: it doesn't consistently pick representatives in same-type groups, doesn't always mark redundant equivalences it introduces, and improperly injects archetypes into concrete types.
Swift SVN r28254
When reading the generic parameters of a constrained protocol
extension, cross-refencing an associated type would perform name
lookup into the protocol extension itself, causing fatal recursion
during deserialization. Fixed by avoiding additional deserialization
when looking for an associated type. Fixes rdar://problem/20812303.
Swift SVN r28228
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
Within the where clause of a constrained (protocol) extension, allow
us to find associated types of that protocol and anything it inherits
via unqualified lookup, e.g.,
extension SequenceType where Generator.Element : Equatable { }
rather than
extension SequenceType where Self.Generator.Element : Equatable { }
Implements rdar://problem/20722467.
Swift SVN r28208
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
Currently GenericSignature::getCanonicalSignature isn't able to canonicalize the set of requirements due to fragile dependencies on generic signatures matching AllArchetypes order of their originating GenericParamLists. However, we shouldn't let that stop us from getting the mangling right, so implement a "getCanonicalManglingSignature" that builds the true canonical signature by feeding it into an ArchetypeBuilder and shedding unnecessary constraints. For now, just handle conformance and base class constraints; still to do are same-type constraints.
Swift SVN r28191
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
Fix an assert-on-valid caused by a broken getSourceRange()
implementation and a missing diagnostic caused by a broken
walker implementation.
Swift SVN r28142
The following declaration kinds can be marked with this attribute:
- method
- property
- property accessor
- subscript
- constructor
Use cases include resolving circularity for bridging methods in an @objc
class, and allowing overloading methods and constructors in an @objc class
by signature by marking some of them @nonobjc.
It is an error to override an @objc method with a @nonobjc method. The
converse, where we override a @nonobjc method with a @objc method, is
explicitly supported.
It is also an error to put a @nonobjc attribute on a method which is
inferred as @objc due to being part of an @objc protocol conformance.
Fixes <rdar://problem/16763754>.
Swift SVN r28126
There was a fair amount of code duplication in handling the various
places where @objc could either be explictly specified or be inferred;
centralize these in a new shouldMarkAsObjC() function. NFC
Swift SVN r28125
AnyObject won't always be a protocol, and it may be de-protocol'ified
well before we get the ability to extend an arbitrary type (if that
ever happens), so ban this for now.
Swift SVN r28120
Emitting an error message about a pattern the user didn't write isn't awesome,
complain about the type requirements of an if/let binding specifically.
Swift SVN r28119
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
The design we landed on for SIMD is to define the vector types as nested types of their element, e.g. Float.Vector4, Int32.Vector2, etc. Update the Clang importer and other mapping facilities to match.
Swift SVN r28087
preserve the original method name.
This heuristic is based on the Objective-C selector and therefore
doesn't really handle factory methods that would conflict with
initializers, but we can hope that those simply don't come up in
the wild.
It's not clear that this is the best thing to do --- it tends to
promote the non-throwing API over what's probably a newer, throwing
API --- but it's significantly easier, and it unblocks code without
creating deployment problems.
Swift SVN r28066
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
@warn_unused_result can be attached to function declarations to
produce a warning if the function is called but its result is not
used. It has two optional parameters that can be placed in
parentheses:
message="some message": a message to include with the warning.
mutable_variant="somedecl": the name of the mutable variant of the
method that should be suggested when the subject method is called on
a mutable value.
The specific use we're implementing this for now is for the mutating
and in-place operations. For example:
@warn_unused_result(mutable_variant="sortInPlace") func sort() -> [Generator.Element] { ... }
mutating func sortInPlace() { ... }
Translate Clang's __attribute__((warn_unused_result)) into
@warn_unused_result.
Implements rdar://problem/18165189.
Swift SVN r28019
This can happen in witnesses, whose context archetypes are composed from the type-level archetypes of the witnessing type, and the method-level archetypes of the requirement. If you have something like:
protocol Foo {
func foo<T>(x: T)
}
struct Bar<T>: Foo {
func foo<U>(x: U)
}
Bar's witness to Foo.foo will end up with two archetypes named "T". Deal with this by having the SIL printer introduce a name mapping that disambiguates colliding archetypes. Refactor the SIL printer to do streaming through the SILPrinter itself, rather than directly on its ostream, so that we make sure it controls how subelements like types are printed, and it can pass the appropriate options down to the AST type printer. Fixes rdar://problem/20659406.
Swift SVN r27991
When deserializing a protocol, the conformance lookup table would not
contain entries for the inherited protocols of that protocol. They
were stashed in the "Protocols" array in TypeDecl (which will
eventually go away), but since there are no conformances for a
protocol, the conformance lookup table never got updated.
Nothing important seems to query this now; that will change soon.
Swift SVN r27967
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
pattern, and can be chained together in conditions just like our other 'if let'
constructs. This only adds functionality, it doesn't change anything yet.
Swift SVN r27932
I debated making isBodyThrowing() do this, but decided that
(1) the better recovery mode is to assume that the function
can throw but (2) making isBodyThrowing() return true on an
invalid function would be really weird.
Tested by the crash testsuite.
Swift SVN r27902
For the most part, this just involves spot fixes to make sure protocol inits follow the same paths as value type initializers would, with the extra wrinkle that we have to ensure we forward the correct metatype from the delegating initializer to the delegatee, in case the initializer is invoked with a different dynamic type from the static Self type. This should handle non-@objc delegations; @objc will need some additional work.
Swift SVN r27900
Preparation to fix <rdar://problem/18151694> Add Builtin.checkUnique
to avoid lost Array copies.
This adds the following new builtins:
isUnique : <T> (inout T[?]) -> Int1
isUniqueOrPinned : <T> (inout T[?]) -> Int1
These builtins take an inout object reference and return a
boolean. Passing the reference inout forces the optimizer to preserve
a retain distinct from what’s required to maintain lifetime for any of
the reference's source-level copies, because the called function is
allowed to replace the reference, thereby releasing the referent.
Before this change, the API entry points for uniqueness checking
already took an inout reference. However, after full inlining, it was
possible for two source-level variables that reference the same object
to appear to be the same variable from the optimizer's perspective
because an address to the variable was longer taken at the point of
checking uniqueness. Consequently the optimizer could remove
"redundant" copies which were actually needed to implement
copy-on-write semantics. With a builtin, the variable whose reference
is being checked for uniqueness appears mutable at the level of an
individual SIL instruction.
The kind of reference count checking that Builtin.isUnique performs
depends on the argument type:
- Native object types are directly checked by reading the
strong reference count:
(Builtin.NativeObject, known native class reference)
- Objective-C object types require an additional check that the
dynamic object type uses native swift reference counting:
(Builtin.UnknownObject, unknown class reference, class existential)
- Bridged object types allow the dymanic object type check to be
bypassed based on the pointer encoding:
(Builtin.BridgeObject)
Any of the above types may also be wrapped in an optional. If the
static argument type is optional, then a null check is also performed.
Thus, isUnique only returns true for non-null, native swift object
references with a strong reference count of one.
isUniqueOrPinned has the same semantics as isUnique except that it
also returns true if the object is marked pinned regardless of the
reference count. This allows for simultaneous non-structural
modification of multiple subobjects.
In some cases, the standard library can dynamically determine that it
has a native reference even though the static type is a bridge or
unknown object. Unsafe variants of the builtin are available to allow
the additional pointer bit mask and dynamic class lookup to be
bypassed in these cases:
isUnique_native : <T> (inout T[?]) -> Int1
isUniqueOrPinned_native : <T> (inout T[?]) -> Int1
These builtins perform an implicit cast to NativeObject before
checking uniqueness. There’s no way at SIL level to cast the address
of a reference, so we need to encapsulate this operation as part of
the builtin.
Swift SVN r27887
Calls to willThrow are marked as read-none so that the optimizer can remove
them. The willThrow builtin is still generated for all throw/rethrow sites,
but I plan to look at this next.
rdar://20356658
Swift SVN r27877
