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
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
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
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
Lower metatype types as @thin or @thick based on whether the type is static and whether the abstraction pattern allows for a thin metatype. Add a '@thick' attribute and require SIL metatypes to always be annotated with either '@thin' or '@thick' to distinguish them from unlowered metatypes.
Swift SVN r11525
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
This is a structural baby step toward lazily filling in protocol
conformances. We always build a ProtocolConformance, then mark it
either "complete" (when it's well-formed) or "invalid" (when it's
ill-formed). At present, the only benefit to this is that it slows
diagnostic cascades from invalid conformances.
Swift SVN r11492
...rather than a raw pointer that points to a buffer with space for N
elements. Just because we *can* get N from context doesn't mean it's
convenient/safe.
No functionality change.
Swift SVN r11488
typealias MyInt: ForwardIndex = Int
There is no real reason to allow this; it's just a static_assert that Int
conforms to ForwardIndex, which would be better spelled some other way.
This only applies to concrete typealiases, i.e. those that simply alias an
underlying type. Associated types can still have both inheritance clauses
and a (default) underlying type.
Swift SVN r11481
- Switch @mutable to be a tri-state attribute that is invertable with @!mutable.
- Move the semantic form of 'mutable' to being a bit on FuncDecl instead of
something in DeclAttrs. The former is a binary bit, the later is a tristate
which differentiates between "not present", "present and set" "present and inverted".
- Diagnose some invalid uses of @mutable, e.g. on class methods.
- Make setters default to mutable, and allow them to be switched with @!mutable.
Swift SVN r11439
Previously, cross-references just carried a chain of identifiers and a
top-level module, plus a type to validate against, a generic parameter index,
or an operator fixity. However, referencing "the first generic parameter
of the prefix function ++ that takes a ForwardIndex" requires /all three/
of these filters to unambiguously select the right declaration.
Now, cross-references consist of a chain of trailing records, one for each
link in the path. There are (currently) five kinds of links:
Type: a declaration that cannot have overloads
Value: a declaration that can have overloads (filtered by type)
Extension: filter to decls within extensions on another module
Operator:
- as the first path piece, an operator declaration
- as a later path piece, a fixity filter for operator functions
Generic Param: an indexed generic parameter of the previous result
This should allow us to uniquely cross-reference any Swift declaration we
need to.
Swift SVN r11399
A SpecializedProtocolConformance intentionally contains all of the
information we need to synthesize the type witnesses from the
underlying (generic) conformance. Do so lazily rather than eagerly,
because we won't always need all of them.
As a nice side effect, we no longer need to serialize the witnesses of
these specialized protocol conformances, so we can save some space in
the Swift module file.
Swift SVN r11303
That is, if we need a type MyIndex<T> to be a valid ForwardIndex, we should
be able to find it in the conformance for BidirectionalIndex, which inherits
from ForwardIndex.
<rdar://problem/15484898>
Swift SVN r11270
NominalTypeDecls and ExtensionDecls have a list of members. Rather than
eagerly populating that list when the nominal or extension is just referenced,
just include a pointer back to the ModuleFile, so that they can be
deserialized when we actually look into the decl. The design here is
general enough that we could do something similar with imported Clang decls.
Clang is even more lazy here: the on-disk representation is a hash table,
so lookup only forces deserialization of members with the same name. We
probably want that some day, but this might be enough to get by for now.
This is groundwork for loading partial ASTs, where eagerly deserializing
members leads to circular references we're not able to handle.
Swift SVN r11219
