Previously, we would require the type checker to be able to build a
conformance, which meant we would actually have to lie in the AST
about having a conformance (or crash; we did the form). Now, we can
form the conformance in the AST and it will be checked in the type
checker when needed. The intent here is to push conformance creation
into the conformance lookup table.
To get here, we had to stop relying on the broken, awful,
ASTContext-wide conformance "cache". A proper cache can come back once
the model is sorted out.
Swift SVN r26250
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
Also, if warning about an accessor that comes from a stored property,
point to the property rather than the (implicit, source-location-less)
accessor decl.
Both of these changes are aimed at improving the presentation in Xcode.
rdar://problem/19927828
Swift SVN r25725
Always perform override checking based on the Swift type
signatures, rather than alternately relying on the Objective-C
selectors. This ensures that we get consistent override behavior for
@objc vs. non-@objc declarations throughout, and we separately make
sure that the Objective-C names line up.
This also allows us to inherit @objc'ness correctly (which didn't
quite work before), including inferring the Objective-C selector/name
(the actual subject of rdar://problem/18998564).
Fixes rdar://problem/18998564.
Swift SVN r25392
The problem here was that the _preconditionImplicitlyUnwrappedOptionalHasValue
compiler intrinsic was taking the optional/IUO argument as inout as a performance
optimization, but DI would reject it (in narrow cases, in inits) because the inout
argument looks like a mutation.
We could rework this to take it as an @in argument or something, but it is better
to just define this problem away: the precondition doesn't actually care about the
optional, it is just testing its presence, which SILGen does all the time. Have
SILGen open code the switch_enum and just have the stdlib provide a simpler
_diagnoseUnexpectedNilOptional() to produce the error message.
This avoids the problem completely and produces slightly better -O0 codegen.
Swift SVN r25254
Previously, we were using the Objective-C names to help determine
whether a declaration is an override or not. This is broken, because
we should determine overrides based on the Swift rules for
overriding, then (later) check that the Objective-C runtime will see
the same override behavior that the Swift runtime does. Address this
problem, both by taking the Objective-C selector out of the equation
when matching overrides (except for diagnostic purposes) and by
performing better validation of the Objective-C names for the
overriding vs. overridden methods/properties.
The motivating case here (from rdar://problem/18998564) is an
Objective-C initializer:
-(instancetype)initString:(NSString *)string;
When trying to override this in a Swift subclass, one naturally
writes:
override init(string: String)
which implicitly has the selector initWithString:. We ended up in an
unfortunate place where we rejected the override (because the
selectors didn't match) with a crummy diagnostic, but omitting the
"override" would result in a different conflict with the superclass.
Now, we'll treat this as an override and complain that one needs to
rename the method by adding "@objc(initString:)" (with a Fix-It, of
course). This fixes rdar://problem/18998564, but it is not ideal: the
complete solution (covered by rdar://problem/19812955) involves
reworking the dance between override and @objc so that we compute
'override' first (ignoring @objc-ness entirely), and let the
@objc'ness of the overridden declaration both imply @objc for the
overriding declaration and implicitly fix the selector. However, such
a change is too risky right now, hence the radar clone.
Swift SVN r25243
Remove the logic that allowed an extension to provide an Objective-C
method that was already declared in the class itself, relying on the
existing Objective-C method redeclaration logic to detect such
conflicts. Fixes rdar://problem/17687082.
Swift SVN r25175
This re-applies r24987, reverted in r24990, with a fix for a spuriously-
introduced error: don't use a favored constraint in a disjunction to avoid
applying a fix. (Why not? Because favoring bubbles up, i.e. the
/disjunction/ becomes favored even if the particular branch is eventually
rejected.) This doesn't seem to affect the outcome, though: the other
branch of the disjunction doesn't seem to be tried anyway.
Finishes rdar://problem/19600325
Swift SVN r25054
@noescape may be interesting to passes in the future, but it currently has no effect except to cause symbol collisions in reabstraction thunks and other places. Since it has no effect, just remove it from SIL for now.
Swift SVN r24925
An optional @objc requirement within a protocol can be left
unsatisfied in a well-formed program. However, there may still be a
conflict within the Objective-C runtime if the conforming class
defines a method with the corresponding Objective-C selector(s) for
that requirement, which means that the Swift and Objective-C semantics
will differ. Diagnose such issues.
More steps along the road to fixing rdar://problem/18383574.
Diagnose conflicts between unsatisfied, optional @objc requirements and
Swift SVN r24830
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
This refactoring is groundwork for saving the cross-module dependencies
in the swiftdeps files as well, so that we know to rebuild files if an
outside file changes (such as a bridging header, another framework's
headers, or another framework's swiftmodule).
Part of rdar://problem/19270920
Swift SVN r24258
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
storage for arbitrary values.
A buffer doesn't provide any way to identify the type of
value it stores, and so it cannot be copied, moved, or
destroyed independently; thus it's not available as a
first-class type in Swift, which is why I've labelled
it Unsafe. But it does allow an efficient means of
opaquely preserving information between two cooperating
functions. This will be useful for the adjustments I
need to make to materializeForSet to support safe
addressors.
I considered making this a SIL type category instead,
like $@value_buffer T. This is an attractive idea because
it's generally better-typed. The disadvantages are that:
- it would need its own address_to_pointer equivalents and
- alloc_stack doesn't know what type will be stored in
any particular buffer, so there still needs to be
something opaque.
This representation is a bit gross, but it'll do.
Swift SVN r23903
rdar://problem/19132138
Make Set<T> visible by removing the underscore. Also, remove the pesky
${_Self} gyb variable that was for a temporary convenience in hiding Set.
Swift SVN r23699
...and thus does not affect downstream files...
...and adopt it in several places:
- when looking up the default type for a literal (test included)
- when looking up the first component in an IdentTypeRepr (test included)
- when deciding which ~= to use in a switch (test forthcoming)
- when a protocol has an operator function requirement (test forthcoming)
- when validating @NSApplicationMain and @UIApplicationMain
- when an enum element shows up unqualified in a switch
- several places where it doesn't matter because we're looking something up
in the standard library.
Part of rdar://problem/15353101
Swift SVN r23670
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
Specifically, when a method defined in the class itself conflicts with
a method defined in an extension of the class, consider the method
defined in the class to be the original declaration (and complain
about the others). This is just QoI that improves predictability, and
is part of rdar://problem/18391046.
Swift SVN r23197
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
