We already know how to call external functions in SILGen, why reimplement all that in IRGen? Instead of representing the thunk operation as a SIL instruction, let's just emit the thunk using existing SILGen machinery. Fixes <rdar://problem/14097136>.
Swift SVN r9576
And tweak the verifier to allow 'convert_cc' over a static FunctionRefInst to remain thin. The SILGen part of <rdar://problem/14097136>.
Swift SVN r9556
Most alloc_stacks emitted by SILGen are temporaries and don't need to be preserved for debug info. It's only the ones that relate to local variables that we need to preserve. Fixes <rdar://problem/15272642>.
Swift SVN r9543
to interpose on the SIL linking process. Under the
following conditions:
- a function is called by the current SILModule;
- that function is transparent and empty in the
generated SIL;
- the SIL linker doesn't find a serialized
version of it; and
- the external client (right now, LLDB) has a
SILExternalSource installed in the SILModule;
the SIL linker will query the SILExternalSource
via lookupSILFunction.
This interface will be used by LLDB to provide
SIL accessors for a program's variables when they
are referred to by Swift expressions.
Swift SVN r9452
This will allow us to differentiate from regular inlined code (as in optimization inlining). Some passes(AllocBocToStack) and debug info would be allowed to be more aggressive/preserve less debug info with mandatory inlined code.
Swift SVN r9339
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
When verifying a SILFunction, walk its CFG, verifying that alloc_stacks and dealloc_stacks balance in stack order, that stack height is consistent coming from all predecessors of a block, and that all alloc_stacks are deallocated prior to returning from a function.
Swift SVN r8985
preceding copy_addr instruction when totally trivial. Adopt this in SILGen, eliminating
a couple dozen destroy_addr instructions from the stdlib and producing more canonical SIL.
Swift SVN r8968
When we walk a ClassDecl, generate its vtable, first pulling in decls from its ancestor classes, then overlaying overridden or new decls as we discover them.
Swift SVN r8947
These will provide a SIL-level representation of class_method dispatch, mapping from dynamically-dispatched SILDeclRefs to SILFunctions so that devirtualization passes will be able to promote a class_method for a statically-known type to a function_ref without going all the way back to the AST.
Swift SVN r8943
Introduces a new kind of function type, GenericFunctionType, that
represents a polymorphic function type with all of its generic
parameters and requirements stored in a more readily canonicalizable
form. It is meant to eventually replace PolymorphicFunctionType, but
for now we build it up in parallel so we can switch over to it
pieacemeal.
Note: this representation is built and then thrown away. We'll start
recording it soon.
Swift SVN r8881
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
Attribute [transparent] on extensions should apply to all members(functions, properties) of that extension.
Addresses radar://15035271.
Swift SVN r8735
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Replace the existing suite of checked cast instructions with:
- unconditional_checked_cast, which performs an unconditional cast that aborts on failure (like the former downcast unconditional); and
- checked_cast_br, which performs a conditional pass and branches on whether the cast succeeds, passing the result to the true branch as an argument.
Both instructions take a CheckedCastKind that discriminates the different casting modes formerly discriminated by instruction type. This eliminates a source of null references in SIL and eliminates null SIL addresses completely.
Swift SVN r8696
