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
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
This reverts commit r19085, which broke the following tests.
Swift :: Constraints/super_constructor.swift
Swift :: expr/postfix/dot/init_ref_delegation.swift
Swift SVN r19098
