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
can make a more precise assertion that all default arguments have the
same owner.
<rdar://problem/20749423> Compiler crashed while building simple subclass code
Swift SVN r28251
If a function has an error result slot, emit debug info for an artificial
function argument "$error" with indirect storage that holds a pointer
to the error object address.
<rdar://problem/20736999> lldb needs to be able to locate the error return location when stepping out of a function
Swift SVN r28229
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
By declaring the parameter's retain count convention, we can avoid the
use of Unmanaged. (See test cases for more examples.)
The last piece of this puzzle is offering a sugared overload with multiple
return values (rdar://problem/20436785) but that will have to wait.
This requires changes to Clang; please update.
rdar://problem/20436757
Swift SVN r28216
This is pretty much a simplification of the existing RawOptionSetType logic; now, instead of generating a bunch of implicit decls, we provide the minimum set of declarations from which the stdlib will be able to generate default implementations of everything else. The new imported declaration looks like this:
struct MyOptions: OptionSetType {
let rawValue: UInt // or whatever raw type
init(rawValue: UInt)
static var A: MyOptions { return MyOptions(rawValue: 1) }
static var B: MyOptions { return MyOptions(rawValue: 2) }
/* etc. */
}
Still hidden behind a staging flag, until the stdlib implementation can land.
Swift SVN r28213
optional evaluation context that produced the optional.
<rdar://problem/20377684> Oscillating fixit for optional chain calling method that returns non-optional
Swift SVN r28212
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
since the type might not match the return type of the function exactly
in that case (CSGen only emits a conversion constraint).
<rdar://problem/20087517> Crash when using .staticShorthand syntax with NSColor/UIColor factories
Swift SVN r28200
The __lldb_expr modules are special as in they are autogenerated by LLDB and meant to not be user-accessible, so showing them adds visual noise for no user benefit
I am open to the notion of adding a flag to swift-demangle to the same effect, but that seems much lower priority
Swift SVN r28195
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
All llvm::Functions created during IRGen will have target-cpu and target-features
attributes if they are non-null.
Update testing cases to expect the attribute in function definition.
Add testing case function-target-features.swift to verify target-cpu and
target-features.
rdar://20772331
Swift SVN r28186
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
(as well as those for lazy properties, which seem to be working already)
This fixes a problem with @NSManaged properties being declared in an
extension in a generated file you're not supposed to modify, which
unfortunately is exactly how Xcode's generating them these days.
rdar://problem/20821582
Swift SVN r28180
Now get() and set() manage determining whether the results are stale,
and getResults() can just rely on that.
Also drive-by fix a data race where we were inserting our results sink
into the cache before it was finished being modified.
Swift SVN r28175
This matches how dispatch_once works in C, dramatically cutting the cost of a global accessor by avoiding the runtime call in the hot path and giving the global a unique branch for the CPU to predict away. For now, only do this for Darwin; non-ObjC platforms don't necessarily expose their "done" value as ABI like ours do.
While we're here, change "once" to take a thin function pointer. We don't ever emit global initializers with context dependencies, and this simplifies the runtime glue between swift_once and dispatch_once/std::call_once a bit.
Swift SVN r28166
Two pieces to this:
- Peephole OptionalEvaluationExpr(InjectOptionalExpr(BindOptionalExpr(X))) to bitcast x to the result type.
- Enhance OptionalEvaluationExpr to delete the failure block if not needed.
This is the same as r28150, but it includes a fix for the case when a non-address-only type
is initializing a contextally-provided-and-addressible buffer, tested by the new
testContextualInitOfNonAddrOnlyType testcase.
Swift SVN r28153
Two pieces to this:
- Peephole OptionalEvaluationExpr(InjectOptionalExpr(BindOptionalExpr(X))) to
bitcast x to the result type.
- Enhance OptionalEvaluationExpr to delete the failure block if not needed.
This is the same as r28111, except that we finalize the initialization in the
address-only case. A reduced testcase for the specific issue is added to
optional-casts.swift.
Swift SVN r28150
