properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
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
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
