and lexical scopes, which can be enabled through the new -g option.
When -g is enabled, line tables and scopes compile all the way
down to DWARF.
Changes to SIL:
- In addition to a SILLocation, every instruction now also has a pointer
to a SILDebugScope (its containing lexical scope).
- Added LexicalScope, which is to be used for all Scopes we want to show
up in the debug info.
Swift SVN r5772
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
referenced symbol with the name, followed by a colon, followed by the type
instead of the type first (following local value references). For example,
instead of:
%1 = function_ref $[thin] ((val : Builtin.Int128), Int64.metatype) -> Int64, @_TSi33_convertFromBuiltinIntegerLiteralfMSiFT3valBi128__Si // user: %4
we now get:
%1 = function_ref @_TSi33_convertFromBuiltinIntegerLiteralfMSiFT3valBi128__Si : $[thin] ((val : Builtin.Int128), Int64.metatype) -> Int64 // user: %4
Swift SVN r5735
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
An [objc] protocol extension of a non-[objc] class from another module might introduce [objc]-ness onto methods from that other module, so we do have to do an extra pass while emitting extensions to make sure the conformance methods get thunked.
Swift SVN r5667
Tag methods as 'isObjC' during decl type-checking if they're mapped into an ObjC protocol conformance. This is better than r5646 because it means we don't need another pass of thunking in SILGen and IRGen, and the thunks will get mapped in a deterministic order and not freak out the buildbot.
Swift SVN r5654
When emitting SIL for classes and class extensions, emit ObjC thunks not only for natively [objc] classes but for methods of native Swift classes used to conform to [objc] protocols as well.
Swift SVN r5648
Treat archetypes with a superclass bound as class-bounded. Change SILGen and IRGen to use the new SuperToArchetypeRef and ArchetypeRefToSuper cast instructions, and drop the old SuperToArchetype and ArchetypeToSuper instructions, which are unneeded because any archetype with a superclass will be class-bounded.
Note that this patch doesn't implement representation optimization for archetypes with superclass bounds--they're still always represented with a worst-case UnknownRefCountedPtrTy.
Swift SVN r5629
When we cast an opaque existential to a concrete type, we steal ownership of the contained value, which leaves the existential container deinitialized. We need a deinit_existential cleanup to deallocate its buffer so it doesn't leak.
Swift SVN r5625
At the highest abstraction level, we pass 'this' to protocol witnesses byref and ownership isn't taken. (The witness thunk for class methods retains 'this' behind the scenes.) Don't disable the cleanup for existential containers on which methods are called so we don't leak it.
Swift SVN r5624
Open us 'a as! T' to allow dynamic casts from archetypes to archetypes, archetypes to concrete types, existentials to archetypes, and existentials to concrete types. When the type-checker finds these cases, generate new Unchecked*To*Expr node types for each case.
We don't yet check whether the target type actually makes sense with the constraints of the archetype or existential, nor do we implement the SILGen/IRGen backends for these operations. We also don't extend 'x is T' to query the new operation kinds. There's a better factoring that would allow 'as!' and 'is' to share more code. For now, I want to make sure 'x as! T' continues to work for ObjC APIs when we flip the switch to import protocol types.
Swift SVN r5611
Since the type metadata for the underlying method will be taken from the class instance, the witness entry point for a class-bounded protocol conformance doesn't need to pass on an extra metatype parameter for the 'This' archetype.
Swift SVN r5595
In this case "naturalUncurryLevel" *might* be uninitialized. I'd prefer
that this code be structured with a switch to prove that all cases
are covered, but that might not be the cleanest solution. I'll
leave that for Joe to decide.
Swift SVN r5565
Add class-bound versions of archetype conversion and existential creation/projection/conversion instructions. Since class-bound generics aren't address-only these instruction variants don't need to indirect through addresses.
Swift SVN r5554
Archetypes and existentials with a class bound can be assumed to have reference semantics, and don't need to be treated as address-only in SIL.
Swift SVN r5553
We were re-counting archetype depth levels and ended up mangling the triangular number of the archetype depth instead of the linear archetype depth. Measure archetype depth starting from zero to fix this.
Swift SVN r5546
Didn't take substitutions into account last time. Always mangle a single-protocol type as a single protocol list, so that substituted protocols mangle as 'PS<n>__' as expected. Also, actually update the tests this time.
Swift SVN r5541
The protocol type mangling is 'P' protocol+ '_', and so needs a trailing '_' to terminate the list, but we were missing the '_' for single-protocol types, which we tried to mangle as a nominal type context.
Swift SVN r5539
Change AssignStmt into AssignExpr; this will make assignment behave more consistently with assignment-like operators, and is a first step toward integrating '=' parsing with SequenceExpr resolution so that '=' can obey precedence rules. This also nicely simplifies the AST representation of c-style ForStmts; the initializer and increment need only be Expr* instead of awkward Expr*/AssignStmt* unions.
This doesn't actually change any user-visible behavior yet; AssignExpr is still only parsed at statement scope, and typeCheckAssignment is still segregrated from the constraint checker at large. (In particular, a PipeClosureExpr containing a single assign expr in its body still doesn't use the assign expr to resolve its own type.) The parsing issue will be addressed by handling '=' during SequenceExpr resolution. typeCheckAssignment can hopefully be reworked to work within the constraint checker too.
Swift SVN r5500
Add an index_raw_pointer instruction that acts like index_addr but for RawPointers, and use it to lower Builtin.gep into SIL instead of into IR.
Swift SVN r5479
If a closure appears in a generic function, the standalone function type for the SIL function needs to include not only the captured values from the outer context, but the generic parameters from the outer context as well. In order to maintain SIL invariants we then need to hand generic parameters from the outer function to the inner closure using a SpecializeInst before partially applying the inner function to create the closure object.
It turns out that ImplicitClosureExprs seem to always be given null parent DeclContexts, so getFunctionTypeWithCaptures was missing adding the generic parameters into implicit closures, causing a crash building the stdlib. This version of the patch has a workaround for the case where a function is generic but a closure in the function is not generic with context (which shouldn't happen if the decl contexts are set correctly).
Swift SVN r5429
If a closure appears in a generic function, the standalone function type for the SIL function needs to include not only the captured values from the outer context, but the generic parameters from the outer context as well. In order to maintain SIL invariants we then need to hand generic parameters from the outer function to the inner closure using a SpecializeInst before partially apply the inner function to create the closure object.
Swift SVN r5424
