This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
GenericSignature's factory method determining whether the signature
was canonical based solely on whether the types in the parameters and
requirments were canonical. While that is currently true (for legacy
reasons), it is wrong: canonicalization also needs to canonicalize
requirements, including same-type requirements, as is currently done
in the canonical signature "for mangling". Move the "this is
canonical" dependency to the point where the canonical signature is
actually computed, so we can change the definition of canonical
signatures later.
While we're here, don't eagerly compute the canonical generic
signature in GenericSignature::getASTContext().
Swift SVN r32309
Now that we have the inheritance lists hanging around, use them: it
makes the conformance lookup table use the same code whether we're
deserializing the conformances or parsing them.
Swift SVN r31383
The conformance lookup table is responsible for answering queries
about the protocols to which a particular nominal type conforms, so
stop storing (redundant and incorrect) protocol lists on the ASTs for
nominal types. Protocol types still store the list of protocols that
they inherit, however.
As a drive-by, stop lying about the number of bits that ProtocolDecl
uses on top of NominalTypeDecl, and move the overflow bits down into
ProtocolDecl itself so we don't bloat Decl unnecessarily.
Swift SVN r31381
We're no longer using this information for generic type parameters or
associated types, so there's no point in leaving this honeypot
around. Note that this information is redundant with what's in the
conformance lookup table already, so it will be going away soon.
Swift SVN r31334
The getConformsTo() callback was responsible for forcing the
collection of the requirements directly placed on an associated type,
which then get added to the archetype builder. This resulted in an
unhealthy dependency on the list of protocols attached to TypeDecl
(which should go away). Instead, retrieve the requirements from the
associated type's archetype (once it's been computed) or directly from
its list of "inherited" types (while we're building the generic
signature for the protocol itself).
Swift SVN r31332
- Disallow @objc on members of non-@objc protocols (the
real reason for this patch)
- Add a separate diagnostic for @objc appearing on members
in non-class, non-protocol types.
- Clean up the code that enforces that @objc can only be
applied to @objc-rooted classes. The diagnostic would
be incorrectly emitted for @objc subclasses of generic
classes.
Fixes <rdar://problem/17273524>.
Swift SVN r31303
This is a step toward weeding out the "getProtocols()" list on
TypeDecl. Now, use the Archetype's list of protocols for the set of
protocols to which the type parameter or associated type
conforms. Since that list is fully canonicalized, it's more generally
reliable. However, start serializing the list of inherited types for a
generic type parameter, so we can print it appropriately.
Swift SVN r31297
Instead of relying on the reference semantics of the base to make this decision, look at the getter and setter to see if either is mutating to decide whether the base of a property lookup should be inout. This should be the final fix for rdar://problem/21578832.
Swift SVN r30887
Two fixes here:
1) Actually check if the ApplyExpr's base is self, instead of assuming
that anything other than a super call is a constructor call on self, to
avoid flagging UnresolvedConstructorExprs formed from Metatype.init()
calls as delegations.
2) Sometimes this is called after parts of the body has been type checked,
here we had the opposite problem, a ConstructorRefCallExpr of a
constructor on self wasn't detected as such.
Fixes <rdar://problem/21914985>.
Swift SVN r30852
More progress on rdar://problem/21578832. A property access off of a reference type may still require an lvalue base if it's a protocol extension implementation with a mutating setter. This gets us another step toward correct type-checking behavior, but the resulting AST still improperly loads the base reference, which leads to SILGen breakage.
Swift SVN r30837
We have to check for cycles of length > 1 here. Also, add a bit to the
AssociatedTypeDecl to ensure the recursive requirement diagnostic is
only emitted once.
Fixes <rdar://problem/17986597>.
Swift SVN r30678
The defer body func is only ever fully applied, so SILGen can avoid allocating a closure for it if it's declared as a 'func', making it slightly more efficient at -Onone.
Swift SVN r30638
The protocol Self parameter is the last generic parameter in the signature,
not the first. While we don't allow protocols nested inside generic classes,
we would still crash in member type lookup from this.
Fixes <rdar://problem/21287703>.
Swift SVN r30635
Otherwise, we end up with declarations with public access that do not
have public 'self' types. These declarations can then be used by other
modules, which may end up trying to access non-external symbols.
This closes a loophole currently in use by the standard library, so
the '_prext_ReverseIndexType' and '_ReverseCollectionType' protocols
become public for now. In order to keep the API impact minimized,
extensions involving these protocols now extend them directly, so that
all of the "private" stuff shows up in one place in the generated
interface. This is not a long-term solution, but it's no worse than
the rest of the underscore rules in the standard library.
rdar://problem/21380336 tracks relaxing access restrictions for protocol
conformances when the witnesses come from a different type, like a
protocol extension. This requires some SILGen work to do correctly.
Finishes rdar://problem/21559986
Swift SVN r30612
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
Generic subclasses of @objc classes are thus no longer @objc, but still
have implicitly @objc members.
Explicit @objc on generic classes or classes that inherit from @objc
classes is now forbidden with a diagnostic. Users need to know that
while they can override Objective-C methods and properties in such
a class, they cannot refer to the class by name from Objective-C code,
since it will not appear in the bridging header.
Fixes <rdar://problem/21342574>.
Swift SVN r30494
'let' properties are settable inside certain initializers, but the
logic was wrong -- in most cases we would fall through and return
true from ::isSettable().
This came up when deserialization (correctly) didn't set the setter
accessibility on a 'let' property, and a read of that property from
a constructor in another struct incorrectly decided the property
was settable, causing a crash.
Fixes <rdar://problem/21559246>.
Swift SVN r30484
Otherwise the verifier can crash because hasType() returns true but
getType() gives us a MetatypeType that hits a null pointer in
desugaring.
The computeType() calls appear in a few too many places for my liking;
would be nice to clean this up further or replace everything with
interface types one day.
Fixes <rdar://problem/19606899>.
Swift SVN r30388
This changes the behavior to match NominalTypeDecls, which don't have a type
until everything is set up either. In a few places we construct TypeAliasDecls
from known types directly, and we have to call computeType().
Fixes <rdar://problem/19534837>.
Swift SVN r30386
This allows any type to conform to ErrorType without having to
implement any requirements, so the requirements can remain
underscored. Implements rdar://problem/21867608.
Swift SVN r30342
Also, checking protocol conformances doesn't depend on any members, just the type.
We don't track dependencies on types separately from members right now, though,
so instead there's now a dummy dependency on 'deinit'.
Swift SVN r30288
- NominalTypeDecl::computeInterfaceType() crash when parent decl
has error type
- createMaterializeForSetPrototype() crash when parent decl
has error type
- Crashes in ConformanceChecker when decl has error type
Fixes <rdar://problem/21583601>.
Swift SVN r29912
All archetypes from outer scopes are fixed (as a lame implementation
restriction), so same-type constraints that involve archetypes from
outer scopres should treat the archetypes from outer scopes as the
representative. Do so, and start eliminating the notion of a "primary"
archetype that was preventing this fix from occurring earlier, so that
"all archetypes" and the set of requirements generated from the
archetype builder still line up.
Fixes rdar://problem/19519590.
Swift SVN r29869
In r26737, Sema was changed to not wrap Self occurring in a protocol
extension in a DynamicSelf. The commit message was rather terse but
I believe this is because the metadata for Self is bound to the static
base type, not the runtime base type.
However, we still need to substitute Self in the return type for the
static base type in the case where the base is an existential,
otherwise we get an open existential type leaking out.
Also remove the default argument for replaceCovariantResultType(),
every call site passed in a value and it seems bad to omit it on
accident.
Fixes <rdar://problem/21433694>.
Swift SVN r29802
Rename existentialConformsToSelf() to existentialTypeSupported(). This
predicate is the "protocol has no Self or associated type requirements"
check, which is a looser condition than self-conformance. This was being
tested to see if the user could refer to the protocol via an existential
type.
The new existentialConformsToSelf() now checks for protocol being @objc,
and for the absence of static methods. This is used as part of the
argument type matching logic in matchType() to determine if the
existential can be bound to a generic type parameter.
The latter condition is stricter, for two reasons:
1) We allow binding existentials to multiple type parameters all sharing
the same generic type parameter T, so we don't want the user to be
able to see any static methods on T.
2) There is an IRGen limitation whereby only existentials without witness
tables can be passed in this manner.
Using the above, the representsNonTrivialGenericParameter() function
has been renamed to canBindGenericParamToExistential(). It now allows
an existential type to be bound to a generic type parameter only under
the following circumstances:
A) If the generic type parameter has no conformances, the match is allowed.
B) If the generic type parameter has at least one conformance, then all
of the conformances on the generic type parameter must be
existentialConformsToSelf() (condition 1 above), and all conformances
on the existential must be @objc (condition 2 above).
Fixes <rdar://problem/18378390> and <rdar://problem/18683843>, and lays
the groundwork for fixing a few other related issues.
Swift SVN r29337
This permits, e.g., extending Array for all Hashable T's. However, it
does not permit extending Array for T == String. Part of
rdar://problem/21142043.
Swift SVN r29107
