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
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
This implements the logic of storing "absent" values as 0 and "present"
values as the enumerator's underlying value plus 1. For enums whose raw
values are arbitrary or small, this is a safe, space-efficient way to add
the "absent" value.
The type has been designed to be used with PointerIntPair, so it converts
(explicitly) to intptr_t, and (explicitly) from any integral type.
Adopt this for use with the Accessibility bits in a ValueDecl.
No intended functionality change.
Swift SVN r20597
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
To answer "did the user specify this, or is it implicit", stick a couple
of is-implicit bits in InfixOperatorDecl, and thread them through
serializaton/deserialization.
Swift SVN r20067
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
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
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
...because you can't match them properly in switches.
In the future, we could consider allowing private enum cases in a
resilient public enum, which essentially forces the user to consider the
default case.
Swift SVN r19620
- 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
(when -enable-access-control is used)
Note that this is currently circumvented when looking up requirements in a
protocol. We're not currently set up to pass along the DeclContext where a
protocol's requirements are requested /from/, so we're just relying on the
fact that the requirements have the same visibility as the protocol in 1.0.
Swift SVN r19355
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
Post-WWDC, we need to update the type checking process to make these kinds of infinite loops impossible without checking special flags.
Swift SVN r18598
Attribute validation is not naturally idempotent, and we shouldn’t need to make it so. Rather, we should only do the validation once. This fixes an immediate issue with @NSManaged in multi-file situations (<rdar://problem/16879162>) and avoids some redundant work.
Longer term, we have a ton of redundant visitation that needs to be addressed <rdar://problem/16905199>.
Swift SVN r18039
Eliminate the duplicate half-broken bridging logic in emitClassConstructorAllocator by referencing foreign initializers through their foreign-to-native thunks, which SILGen knows how to emit already. Do the same thing for factory initializers by suppressing their normal allocating initializer codegen and just referencing the usual foreign-to-native thunk for them. This fixes <rdar://problem/16853205> because we get the ownership thunking right now.
Swift SVN r17840
This preserves more of source info (e.g. API name location) and simplifies things since
we don't have to construct ParamDecls for the unnamed parameters later on.
Swift SVN r17828
