Parse function declarations with the form
func murder inRoom(room: Int) weapon(Int) {}
where the function name ("murder") is separated from the parameter
names. This is the same style used in initializers, i.e.,
init withCString(cstr: CString) encoding(Encoding)
Swift SVN r15140
Instead of referencing them by name, serialize a reference to their
storage decl instead, then note which accessor to retrieve.
Uncovered by Chris's override work in r15051...thanks, Chris!
Swift SVN r15063
Previously, we were cloning the default arguments completely, which
meant code duplication (when inheriting within a module) or simply a
failure (when inheriting across modules). Now, we reference the
default arguments where we inherited them, eliminating the
duplication. Part of <rdar://problem/16318855>.
Swift SVN r15062
If a subclass defines no subobject initializers and all of its stored
properties have initial values, "inherit" all of the subobject
initializers of its superclass by creating a new initializer with the
same signature that overrides (and chains to) the corresponding
subobject initializer of its parent. Do this instead of blindly
creating a default initializer.
Note that we aren't yet doing this for generic initializers. That will
be a separate step.
Swift SVN r14995
Let ArchetypeType nested types and PotentialArchetypes be bound to concrete types in addition to archetypes. Constraints to outer context archetypes still suffer type-checker issues, but constraints to true concrete types should work now.
Swift SVN r14832
Before, we would hit one of the error conditions before updating the path
trace, which was misleading at best.
No functionality change.
Swift SVN r14815
The standard library likes to have default definitions for associated types,
which is good. Often the /choice/ of default type, however, is a type that
(indirectly) conforms to the very protocol containing the associated type.
Rather than try to make sure everything is present all at once, just delay
the deserialization of the default definition until it's actually requested.
This does swell the size of AssociatedTypeDecl by two words. I've filed
<rdar://problem/16266669> to remind myself to try to reduce this.
Part of <rdar://problem/16257259>
Swift SVN r14809
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
to the archetypes of their generic parameter declarations.
This was a major inconsistency that was causing a lot of
problems with deserialized generic functions in the presence
of chained module files. In particular, what would happen is
that all the deserialized uses of the archetype would be
mapped to a freshly-created archetype, but the GenericParamList
would refer to GenericTypeParamDecls deserialized from
(potentially) a different ModuleFile and therefore using a
different archetype (since the deserializer assumes that
different modules never share archetypes).
The fix relies on processing a generic parameter list before
any references to the archetypes. Unfortunately, we have
bogus references to archetypes in substitution lists scattered
everywhere in SIL and the AST. I've introduced a really
gross hack where we allow archetypes to be created in that
way but just drop them (in favor of the parameter's archetype)
after processing the generic parameter list; this should
work as long as all the decontextualized references are
basically pointless, but like I said, it's gross, and I've
filed rdar://16240384 to clean it up.
Swift SVN r14694
If we got just the wrong chain of dependencies, we'd create two VarDecls
for the same variable. I'm not sure if any of the other decls have the
same problem, but better safe than sorry.
I couldn't think of a small test case for this, but it does fix the one
in the Radar.
<rdar://problem/16205936>
Swift SVN r14625
The 'override' attribute indicates that the given declaration, which
may be a method, property, or subscript, overrides a declaration in
its superclass. Per today's discussion, the 'override' attribute must
be present if and only if the corresponding declaration overrides a
declaration in its superclass.
This implements most of <rdar://problem/14798539>. There's still more
work to do to on property and subscript overrides.
Swift SVN r14388
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from
the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're
serializing a complete definition. This fixes issues with us getting the
wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the
generic param list to correctly come before we check if the SILFunction block
is empty, and we add a kludge to keep the JIT from crapping itself when it sees
the same transparent definition in multiple REPL lines' modules
<rdar://problem/16094902>.
The previous commit solves a problem this exposed at r14050 in inout deshadowing
that caused memory corruption when transparent functions were imported. This
should now be safe to commit.
Swift SVN r14109
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the generic param list to correctly come before we check if the SILFunction block is empty, and we add a kludge to keep the JIT from crapping itself when it sees the same transparent definition in multiple REPL lines' modules <rdar://problem/16094902>.
Swift SVN r14030
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
This gets me a clean build when applied against r13984.
Swift SVN r14005
Previously, we would just parse vars and subscripts with no definitions,
then let getters and setters be referenced arbitrarily later. This was
problematic for a number of reasons, not least of which, the .sil file
might be invalid.
Instead, change sil to require that a protocol style definition indicate
whether a vardecl/subscript is computed or not, and whether it is both
get-able and set-able, e.g. like "var x : Int { get }". Change the
sil printer to print decls in this form, and change the SILParser to
make SILDeclRef::Func values instead of ::Getter/Setter values.
One thing that this exposed is that we weren't correctly serializing the
accessor state in modules, so accessors would get detatched from their
AbstractStorageDecls when deserialized (and in fact, their ASD never got
deserialized at all in some cases). Fix this in the serialization of
the accessors.
NFC, other than the SIL printer and parser.
Swift SVN r13884
GenericSignatures with no params or requirements are a bug, so verify that they don't happen by making GenericSignature::get return null and GenericFunctionType assert that it has a nonnull signature. Hack Sema not to try to produce nongeneric GenericFunctionTypes when a function in a local type in a generic function context is type-checked; there's a deeper modeling issue that needs to be fixed here, but that's beyond the scope of 1.0. Now that GenericSignature always has at least one subtype, its factories no longer need an independent ASTContext argument.
Swift SVN r13837
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
There are some straggling references to the context generic param list, but nothing uses the non-interface param or result types anymore!
Swift SVN r13725
SubscriptDecl is created, then the accessors are installed on it.
This allows us to create the subscript decl before the accessors
have been parsed, allowing us to build the subscript even in invalid
cases (better for later error recovery).
More importantly, this allows us to add it to Decls before calling
parseGetSet, so we can now make parseGetSet add accessors to Decls
without breaking source order (something that deeply upsets the IDE
features).
With all this untangled, we can now remove the 'addAccessorsInOrder'
hack where we parsed the accessors and then later tried to figure out
which order they came for the purpose of linking up the AST: accessors
now work just like everything else.
Swift SVN r13708
now that they are implicitly updated. This exposes two things:
1) we're unncessarily serializing selfdecls in ctors and dtors.
2) The index pattern of a SubscriptDecl has no sensible DeclContext that
owns variables in it.
I'll deal with the first tomorrow, I'm not sure what to do with
the second one.
Swift SVN r13703
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
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
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
