with FuncDecls. This allows us to eliminate special case code for handling
self in various parts of the compiler.
This also improves loc info (debug info and AST info) because 'self' now
has a location instead of being invalid.
I also took the opportunity to factor a bunch of places creating self decls
to use similar patterns and less copy and paste code.
Swift SVN r13196
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
When we type check the signature of a method, determine which method
it overrides (if any) at that time. This ensures that we always have
this information for name lookup (per <rdar://problem/15932845>).
As part of this, start to make the overriding rules a little more
sane. John has worked out more of the model here, but this patch:
- Considers an Objective-C method an override of another Objective-C
method if the selectors match and the type vs. instance-ness of the
methods match. The method types are checked for consistency
(subtyping is okay).
- Diagnoses when a method overrides more than one method from a
superclass, and
- Eliminates the "cannot overload method from a superclass"
diagnostic, which is overly pedantic and oddly limiting.
Note that we lose some amount of checking here. Specifically, we don't
have a good place to check that one has not provided two different
methods that override the same superclass method. The older code did
that (somewhat), and it's not a trivial problem to solve efficiently.
This fixes the part of <rdar://problem/15597226> that is needed for
<rdar://problem/15932845>. It still doesn't handle properties,
subscripts, and undoubtedly other issues.
Swift SVN r13108
When a let decl is in an @objc class, it is converted to StoredObjC
storage. However, since it is not mutable, it should only have a getter
synthesized for it, not a setter.
Swift SVN r13096
getInterfaceSelfType, inline them into their caller. This
has the nice effect of moving getSelfTypeForContainer into
Decl.cpp instead of being in DeclContext.cpp (which never
made sense to me).
Swift SVN r12984
properties have accessors, we have an amazing property: everything that we
want to form a getter or setter for ... really has one! I suspect many things
can be simplified now, but the first on the chopping block is
StorageDecl::getGetterType (and its three friends) which is now always exactly
just getGetter()->getType().
Swift SVN r12983
extension.
Eventually, extensions won't necessarily have the same
parameter list as the declarations they extend, and this
makes it easier to make that work.
Swift SVN r12940
represented: they should have an explicit getter and setter synthesized by
Sema, instead of by silgen and tenuously tied in by IRGen.
There is more work to be done on this (e.g. I need to figure out how to get
the bodies properly type checked), so it is hidden behind a new
-enable-new-objc-properties flag.
Swift SVN r12907
This allows us to have references to type parameters within the
generic type parameter list. This occurs, for example, with
DynamicSelf methods within generic classes.
Swift SVN r12809
To get here, make the implicit 'self' parameter a bit more like a
parsed parameter, by giving it a trivial TypeRepr so that pattern
validation will validate the type. This latter piece is important for
DynamicSelf, because we need the interface type of the function to
refer to the implicit generic parameter while the actual type refers
to the archetype.
Swift SVN r12757
Make them cheap to compare. We may want to hang an ArchetypeBuilder off of them to cache archetypes within the signature context at some point too.
Swift SVN r12630
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
getGetterType()/getSetterType() (and their 'interface'
variants) all become trivial. Lets let sema worry about this
stuff instead of duplicating the logic in libast. NFC
Swift SVN r12563
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
move OverriddenDecl and usesObjCGetterAndSetter() up to it.
This allows usesObjCGetterAndSetter to subsume the logic
for subscript decls as well.
Swift SVN r12535
1) Revert my change to give DeclContext a dump method, it confuses the debugger.
2) Refactor SILGen::requiresObjCPropertyEntryPoints out to
VarDecl::usesObjCGetterAndSetter.
Swift SVN r12526
<rdar://problem/15785677> allow 'let' declarations in structs/classes be initialized in init()
Our model is that 'let' ivars are fully mutable in init() but are immutable everywhere else.
Swift SVN r12509
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
An initializer outside of the class's defining module won't
necessarily have access to all of the stored properties of the class
to initialize them (and wouldn't be resilient against changes even if
it did), so it must delegate.
Swift SVN r12302
This attribute states that all stored properties within the class must
provide initial values. This will allow us to move stored property
initialization into Objective-C's post-allocation initialization hook,
.cxx_construct.
Swift SVN r12228
While we're here, cache the result of looking for delegation or
chaining calls within ConstructorDecl. Only Sema and SILGen for the
body of the constructor care, so we don't serialize this
information. Rather, we have a faster-path to recompute it should
someone ask again after it was cached.
Swift SVN r11969
- Change the AST for get/set functions to take self @inout only when they
are @mutating. Setters default to @mutating, but can be explicitly marked
@!mutating. Getters default to not mutating, but can be marked @mutating.
This causes self to follow.
- Change sema to handle semantic analysis of a.y (and subscripts) based on
whether the computed type of a allows mutation (which is when 'a' is an
lvalue, or both the getter and setter are non-mutating). When both of
these conditions fail, 'a.y' has rvalue type, and is thus non-mutable.
- Rework silgen of lvalues to handle this: now properties and subscripts
can have rvalues as bases, which means that all the lvalue machinery needs
to be able to handle the full generality of base expressions (which is
what my recent patches have been paving the way towards).
- Rework silgen of rvalues to similarly handle rvalue bases.
- Rework silgen of both to handle the case where the AST has found a base
expression that is an lvalue, but where only a non-mutating getter or
setter is needed. Right now, we just emit a load of the lvalue, but
it would result in better code to not require the base be an lvalue at
all (todo).
The upshot of all of this is that we are doing *much* less AST-level
materialization (MaterializeExpr goes down), we generate a lot better SIL
out of SILGen in many cases, and 'self' being an rvalue in properties and
subscripts means that we correctly reject code like the examples in
test/Sema/immutability.swift.
Swift SVN r11884
When we see an uncurried nested PolymorphicFunctionType, such as <T> Foo -> <U> Bar -> Bas, pull the deepest generic parameter list out into the lowered SIL function type, so that dependent archetypes at all levels get properly represented in the generic parameter list, and we can map them to dependent generic types.
Also, apparently deserialized generic param lists get different archetypes from the corresponding deserialized generic param decls. Weird, but hopefully this will all be over soon, so roll with it, man.
Swift SVN r11809
For now, derive the generic signature from the contextual generic parameter list, so we can incrementally move producers and consumers of SILFunctionTypes to the new model independently. We derive the generic signature, but we can't yet derive the interface parameter and result types in all cases due to bugs in how we lower nested generic SILFunctionTypes. NFC yet.
Swift SVN r11722
struct methods. This does not including properties and subscripts,
but covers the bulk of the change. The implication of this is that
the compiler now rejects mutations of self in a non-@mutating method,
and rejects attempts to call a @mutating method from a non-@mutating
method.
Along with this:
- Fix a refcounting bug in SILGenExpr where I emitted multiple releases
in the rvalue member_ref_expr case, which was exposed by the
testsuite now that rvalues are being used a lot more.
- Change a few native binding things in objc/Foundation to understand
that String is passed by value now when calling size() and that
you can't take the address of self in a non-mutating method (this
should probably pass the components by value instead of passing
&self, for better performance). I filed rdar://15726720 to track
this.
- Update a ton of testcases. We now don't materialize nearly as much
as we used to.
- Brutalize the test/stdlib/Getopt.swift testcase to work, now that
the "GetoptLongOptions().noArgument("foo")" builder pattern doesn't
work anymore (noArgument is a @mutating method, which isn't allowed
on an rvalue temporary).
Swift SVN r11662
