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 is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
This reverts commit r22829, because reverting r22828 depends on it.
Reverting r22828 because it
was apparently causing an assertion on the bot:
Swift SVN r22830
This lets us reliably print and parse opened archetypes across different compiler invocations. Using a source-related locator would be ideal, but that's complicated by the need to manufacture, print, and parse these things during SIL passes, so cop out and burn a UUID for now.
Swift SVN r22385
This patch adds SILGen for the API availability (#os(...)) construct. To do so,
it (1) adds version range information to the AvailabilityQueryExpr AST in Sema,
during type refinement context construction; and (2) uses that version range,
during SILGen, to emit a call to the standard library's
_stdlib_isOSVersionAtLeast function.
Swift SVN r22348
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
Like the Clang decls, this happens at the end of the type-checking, just as
a simple walk through the loaded decls of the loaded modules. This caught
all of the issues in this commit series and will hopefully keep us honest in
the future.
(By the way, we don't verify right when we return a deserialized decl for the
same reason we don't verify right when we return an imported decl: parts of
the decl may be delayed, and (a) we don't want to force things to be imported
or deserialized sooner than necessary, yet (b) we want to verify as much as
possible.)
rdar://problem/16968891
Swift SVN r22200
The second type of WitnessMarker for deserialized GenericSignature is null.
But the second type for parsed GenericSignature is not null, causing type
mismatch error when linking a SILFunction.
This commit ignores the second type of WitnessMarker when profiling the
GenericSignature.
rdar://17998988
Swift SVN r21178
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
Previously, we only retained the module in which a normal protocol
conformance occurred, which meant we either had to go searching for
the appropriate extension (yuck) or do without that information. This
is part of the separating-extension-archetypes work.
Swift SVN r20793
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
As a first step toward addressing <rdar://problem/17507421>, introduce a type property we can use as a more general replacement for is<LValueType> that also catches tuples of @lvalues (and in the future, potential (@lvalue T)? optional-of-lvalue formations) and other types that need to be loaded in non-assignment contexts.
Swift SVN r20371
Add a set of _preconditionOptionalHasValue intrinsics that merely test that an optional has a case. Emit an lvalue ForceValueExpr as a physical lvalue, first asserting the precondition then projecting out the Some payload.
Swift SVN r20188
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
Previously, bridged value types and their corresponding Objective-C
classes allow inter-conversion via a number of user-defined conversion
functions in the Foundation module. Instead, make this a general
feature of the type checker so we can reason about it more
directly. Fixes <rdar://problem/16956098> and
<rdar://problem/17134986>, and eliminates 11 (half) of the
__conversion functions from the standard library and overlays.
A few notes:
- The XCTest changes are because a String can no longer directly
conform to CVarArg: this is a Good Thing (TM), because it should be
ambiguous: did you mean to pass it as an NSString or a C string?
- The Objective-C representations for the bridged collections are
hard-coded in the type checker. This is unfortunate and can be
remedied by adding another associated type to the
_BridgedToObjectiveC protocol.
Swift SVN r19618
These types are needed by enough of the stack now that it makes sense to centralize their lookup and caching onto the AST context like other core types.
Swift SVN r19029
not a struct wrapping an Optional.
Among other things, this means you can now pattern-match on
an IUO. It also makes it more convenient to build and destroy
them.
SILGen's type lowering should probably canonicalize one kind
of optional to the other so that we don't get silly abstraction
costs from conversion.
Swift SVN r18991
s/_dictionaryCheckedDownCast/_dictionaryDownCastConditional/g
s/_dictionaryBridgeFromObjectiveC/_dictionaryBridgeFromObjectiveCConditional/g
Swift SVN r18931
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
This is better than requiring people to go through Ctx.getModule() using
Ctx.StdlibModuleName. There aren't that many cases of this, but they
shouldn't be using a completely different API.
The default behavior remains the same: if the standard library has not been
loaded, null will be returned.
Refinement of r18796, which modified the behavior of SourceFiles to assume
that the standard library had already been loaded.
Swift SVN r18813
