semantically valid way.
Previously, this decision algorithm was repeated in a
bunch of different places, and it was usually expressed
in terms of whether the decl declared any accessor
functions. There are, however, multiple reasons why a
decl might provide accessor functions that don't require
it to be accessed through them; for example, we
generate trivial accessors for a stored property that
satisfies a protocol requirement, but non-protocol
uses of the property do not need to use them.
As part of this, and in preparation for allowing
get/mutableAddressor combinations, I've gone ahead and
made l-value emission use-sensitive. This happens to
also optimize loads from observing properties backed
by storage.
rdar://18465527
Swift SVN r22298
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
Use this in calls to TypeBase::getTypeOfMember() that were relying on
archetypes solely because they were using EnumElementDecl::getArgumentType().
Swift SVN r22205
body of a function twice.
This is almost taken care of by careful ordering, but it gets
all screwed up by synthesized accessor functions. Just give
up and keep a bit.
Swift SVN r22019
generates them.
Modify getAsCanonicalGenericSignature to dump same-type requirements last.
Also mix the conformance requirements on assocaited archetypes with the witness
markers.
SILParser used to put witness markers for all assocaited archetypes, then
add same-type requirements, and finally the conformance requirements on
associated archetypes. This causes mismatch types between deserialized
SILFunctionTypes and parsed SILFunctionTypes.
rdar://17998988
Swift SVN r21423
When trying to implement deduplication of results, found and fixed an issue
with loose checks for generic overload checking.
rdar://17995317
Swift SVN r21276
method has the convenience attribute on it when inferring the type of an
init that contains no self.init or super.init method. This allows us to
properly infer that these things are delegating initializers, which trickles
down to emitting:
a.swift:7:3: error: self.init isn't called on all paths in delegating initializer
for:
required convenience init(foo: Int) {
}
instead of doing DI as though the initializer was a root init.
Swift SVN r21120
This is a simple, trivialy, not-even-half-way-there solution to weak
leaking of Objective-C classes introduced after the deployment
target. It only works for Objective-C classes and C global variables
that Clang consideres to be "weak imported". However, this bare
minimum should be enough to develop an app (by jumping through various
hoops) that uses new functionality when its
available. <rdar://problem/17296490>, which I've restricted in scope
to capture this.
Swift SVN r20956
We were checking for exact type equality of the DeclContexts, which
will not hold when extensions have their own archetypes. A near-term
fix would be to use interface types, but checking the nominal types is
a better long-term solution.
Swift SVN r20768
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
This adds generic parameters and generic signatures to extension
declarations. The actual generic parameters just mirror what is
available on the extended type; however, it is filled in via extension
validation, which is handled lazily.
This is a NFC step toward decoupling the archetypes of extensions from
the archetypes of the extended types <rdar://problem/16974298>.
Swift SVN r20675
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
They don't get dispatched, but we should go through their native entry point instead of the ObjC thunk. Fixes <rdar://problem/17606834>.
Swift SVN r20105
that important protocols are not hidden
The rule essentially remains the same -- underscored symbols are stdlib
implementation details and users should not be relying on them. (Even
protocols like _Collection, are conceptually implementation details -- they are
not a part of the original design and we would like to remove them as soon as
the bugs are fixed.)
But since protocols define requirements for user types, we need to display even
underscored protocols, except for _Builtin* protocols, which can never be
satisfied by a user type.
rdar://16986307
Swift SVN r20083
Our poor non-resilient vtables can't handle new methods being added to
superclasses, so when we do vtable layout we need to know that the
superclass is complete. If the superclass's initializers were never needed,
though, we would have never added them to the vtable, and we'd end up with
the wrong offset for all subclass methods.
<rdar://problem/17645615>
Swift SVN r19998
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
accessors due to syntax errors.
This allows AST clients to consult the source range of the braces for
computed properties even when there are errors.
Addresses the first part of <rdar://problem/16747499>.
Swift SVN r19843
SIL SROA needs to know when a struct's visible fields actually completely make up the struct value, which becomes an issue if we start importing structs with yet-unrepresentable unions and bitfields. Track this in the ClangImporter, and add an 'aggregateHasUnreferenceableStorage' predicate to SILType to make it easy for passes to query. Part of <rdar://problem/17555966>.
Swift SVN r19720
