Also, the extra inhabitant lookup for native Swift no-payload enums is inappropriate for C enums. For now, expose no extra inhabitants from C enums.
Swift SVN r10006
SILGen, SIL passes, and IRGen have been factored out of main() into a
helper function "performCompile", which is called separately for each
input file. This will eventually be used to avoid rebuilding an entire
target when a single file changes.
Known issues:
- @transparent functions are not inlined across file boundaries.
<rdar://problem/15366167>
- Some work and caches could definitely be shared between "compilations".
- Unless all files use the same LLVMContext, we get crashes.
<rdar://problem/15283227>
- This mode is not compatible with -emit-module, so building a library still
requires using single-file mode, or performing two invocations of swift.
Eventually we'll have an AST-merging tool to combine the ASTs serialized
into object files. <rdar://problem/15246467>
But the long-term design is to have these separate compilations happen in
separate cc1-like processes, so we shouldn't spend too much time optimizing
this.
Swift SVN r9889
Produce protocol descriptors when we see a protocol definition in the current module. If the protocol is @objc, go through the existing path for generating full Protocol* metadata for objc objects; otherwise, emit our layout-compatible but strong-external-linkage Swift protocol descriptor record.
Swift SVN r9867
Whatever kind of Swift decl we cons up for a Clang enum, add it to the externals list so we can pick it up and emit Swift metadata for it in IRGen. Fixes <rdar://problem/15242452>.
Swift SVN r9801
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
The only real change here is that module-wide IR (autolinking and ObjC
runtime flags) have been pushed up from emitTranslationUnit (now
emitSourceFile) to its only caller, performIRGeneration.
Swift SVN r9075
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
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
Add a SILLinkage mode "Deserialized" to make sure IRGen will emit
hidden symbols for deserialized SILFunction.
Inside SIL linker, set Linkage to external if we only have a declaration for
a callee function.
Both sil block and decl block in a module can emit an array of substitutions.
To share the serialization between SILSerializer and Serializer, we modify
the interface to pass in the abbreviation codes to write functions and to
pass in a cursor to read functions.
We now correctly handle the serialization of Substitutions in SpecializeInst.
For a deserialized SILFunction, we now temporarily set its SILLocation and
DebugScope to an empty FileLocation. Once mandatory inliner sets the SILLocation
to the location of ApplyInst, a null SILLocation and a null DebugScope
may work for a deserialized SILFunction.
Update testing cases to reflect that we are now inlining transparent functions
from modules, or to disable SILDeserializer for now (I am not sure how to update
those testing cases).
Swift SVN r8582
Introduce an EnumCaseDecl for source fidelity to track the 'case' location and ordering of EnumElementDecls. Parse a comma-separated list of EnumElementDecls after a 'case' token.
Swift SVN r8509
Improve the type checker to create implicit DestructorDecls, tighten the
assertion in ImplicitReturnLocation::getImplicitReturnLoc(), and add a verifier
check that a class in a type checked AST always has exactly one destructor.
SILGen used to generate a destructor if the class does not have a
DestructorDecl. SILGen used to put the ClassDecl inside the SILLocation for
the destructor SIL code. This is not a very clean solution: in this case
ImplicitReturnLocation SILLocations contain ClassDecl, which is surprising.
rdar://14970972 Implicit destructors should have AST nodes
Swift SVN r8498
Now that all [objc] constructors have a suitable "init" selector, emit
an Objective-C thunk for the initializing constructor (not the
allocating constructor!) with that selector, and make sure it shows up
in the Objective-C metadata.
With this, we can write a Swift constructor "constructor()" to
override "-init"; see the change to ListMaker that exercises this.
Joe or John: I'd love a review of these.
Swift SVN r8373
Previously, we predicated this on the original class itself being
[objc] or the extension having adopted any [objc] protocols. Extend
that definition to consider one-off, explicitly-marked [objc] methods
or properties.
Since we're here, and make sure we can reference the Objective-C
metaclass in the interpreter even when the original class wasn't
marked [objc].
Swift SVN r8310
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
Lazily-generated currying thunks will require the same IR-level linkonce_odr linkage as clang thunks currently do, so generalize the name of the existing SIL-level linkage specifier 'clang_thunk'.
Swift SVN r8122
When loading a selector in the JIT, we need to call
sel_registerName(). This was manually coded in two places and missed
in a third, so factor it appropriately.
Swift SVN r8082
Among other things this enables mangled names for tuples.
This adds a pointer to the DeclContext to SILFunction and which is used
to provide the necessary context to the Mangler.
Fixes rdar://problem/14808764 and rdar://problem/14813658.
Swift SVN r8070
To instantiate the value witness table for generic types, we were instantiating the generic type at () for all of its parameters and hoping for the best. That's insane. Instead, let's use the DeclaredTypeInContext for the generic type so the archetypes actually get usefully bound inside the witnesses. This way, the witness implementations should be independent of generic parameters, so we can also mangle the unbound type into the witness symbols.
Swift SVN r7901
DebugTypeInfo. This is based off the observation that no two types that
share the same canonical type can have different storage and alignment
and has the benefit of being able to locate the debug info for a type
described by a meta type.
Swift SVN r7578
This currently only works with Clang modules, since there's no way to specify
requirements for a Swift module.
Also, update some tests with a fake Foundation module to make sure they pick
up the fake Foundation adapter instead of the real one.
Swift SVN r7490
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
This is a baby step toward eliminating GenericParamList from
PolymorphicFunctionType, fixing up the easy callers. No functionality
change.
Swift SVN r7370
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
When injecting the payload case of the union, pack the payload value into its native representation, and add zeroed extra bits if needed. When injecting the non-payload cases, assign them extra inhabitants if we have them, spilling into setting extra bits if needed.
Swift SVN r7323
However, the default literal types /are/ looked up in the current TU, so
that they can be changed. It's questionable whether or not this should
include "Slice" and "Dictionary", though.
If the module "swift" isn't available, we fall back to TU-based lookup,
which is necessary to build the standard library itself.
Full list of values now looked up in "swift":
ArrayBound
ArrayLiteralConvertible
Bool
BuiltinCharacterLiteralConvertible
BuiltinFloatLiteralConvertible
BuiltinIntegerLiteralConvertible
C_ARGC
C_ARGV
CharacterLiteralConvertible
DictionaryLiteralConvertible
Enumerable
Enumerator
false
FloatLiteralConvertible
IntegerLiteralConvertible
LogicValue
MaxBuiltinFloatType
MaxBuiltinIntegerType
Optional (for T?)
print
Slice (for T[] but not as default array literal type)
StringInterpolationConvertible
StringLiteralConvertible
true
Swift SVN r7262
