If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
Emit witnesses for initializer requirements. Allow the use of
initializer requirements on archetypes; existentials don't work due to
<rdar://problem/16165890>.
Swift SVN r14356
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
We can now form witness tables for both properties and subscripts, but still can't
call them. Also, only computed properties can fulfill a protocol requirement (which
is tracked by rdar://15912000).
Swift SVN r14137
This has the nice "side effect" of making overrides of generic
functions work better, fixing the remaining type checker issues from
<rdar://problem/15836098>.
Also synthesize the types for derived RawRepresentable conformances
directly rather than going through the type checker, so we get the
interface types right.
Swift SVN r14066
separately from the get/set value. There is no exposed way in the
source language to use this, and this causes shorter term annoyance.
I chose to flatten the value and indices so the value comes first.
In principle, this allows us to completely eliminate our ObjC importer
thunks. I haven't removed them though, because they might be useful
for something else.
Swift SVN r14049
Don't try to set the generic params of a reabstraction thunk until we've established it hasn't already been defined, fixing an issue where the same generic reabstraction pattern occurred in different contexts and we ended up clobbering the archetypes of a thunk that was already defined in terms of other archetypes.
Swift SVN r13964
This isn't testable yet, as it is blocked by at least two things:
1. we can't put curried functions into witness tables (rdar://16079147),
which is a problem given that subscript accessors are curried on their
index argument.
2. accessors cannot silgen is curried form, we currently die in mangling.
Swift SVN r13947
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
<rdar://problem/15967182> fixed the inference of @objc for
initializers, but our SILGen predicate deciding whether to perform
Objective-C dispatch was failing to heed the @objc bit on
constructors. Fixes <rdar://problem/16041090>.
Swift SVN r13787
Most of the complexity here is teaching SILGen how to handle closed-over direct
accesses to observing properties, since all of the getter/setter/willSet/didSet
members of the property are actually full closures when in a function body.
We generate correct but really terrible code here, since the setter captures the
willset/didset members themselves. I'm not worrying about the performance of
this construct though, functionality is what matters.
Swift SVN r13778
We still glue the generic params of the requirement to the generic params of the conformance, but now we do it without relying on TypeLowering.
Swift SVN r13771
Pass the context generic params for a reabstraction thunk down to getOrCreateReabstractionThunk from the enclosing function, where it can either use them to define a new thunk or ignore them if it has an equivalent thunk already. Tweak the mangling of reabstraction thunks to use the generic signature with decontextualized "from" and "to" types instead of the generic param list.
Swift SVN r13763
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
Edge SILFunction one step closer to independence from SILFunctionType context by taking the generic param list as a separate constructor parameter, and serializing those params alongside the function record. For now we still pass in the context params from the SILFunctionType in most cases, because the logic for finding the generic params tends to be entangled in type lowering, but this pushes the problem up a step.
Thanks Jordan for helping work out the serialization changes needed.
Compared to r13036, this version of the patch includes the decls_block RecordKind enumerators for the GENERIC_PARAM_LIST layouts in the sil_block RecordKind enumerator, as Jordan had suggested before. r13036 caused buildbot failures when building for iOS, but I am unable to reproduce those failures locally now.
Swift SVN r13485
Specialization and devirtualization can produce legitimate direct references to them from outside, and at least in the short term all conformances will be public.
Swift SVN r13287
Have SILGen mark all variables bound from pattern bindings without initializers (and *only* ones without initializers) with mark_uninitialized [var] pseudo instructions. On the DI end, *only* consider mark_uninitialized instructions for DI analysis. This has many benefits:
- DI doesn't waste time analyzing locals that are trivially initialized in the original source code.
- DI doesn't try to mangle canonical SIL that has been inlined from transparent functions, which may have been optimized into a form DI isn't written to understand.
While we're here, fix an issue with DCE where it would try to kill unused MarkUninitialized instructions. Although MarkUninitialized has no side effects, it still is semantically important to raw SIL, and can't be killed.
Chris did most of the work here; I just finished updating tests and fixing bugs.
Swift SVN r13247
Edge SILFunction one step closer to independence from SILFunctionType context by taking the generic param list as a separate constructor parameter, and serializing those params alongside the function record. For now we still pass in the context params from the SILFunctionType in most cases, because the logic for finding the generic params tends to be entangled in type lowering, but this pushes the problem up a step.
Thanks Jordan for helping work out the serialization changes needed.
Swift SVN r13036
properties have accessors, we have an amazing property: everything that we
want to form a getter or setter for ... really has one! I suspect many things
can be simplified now, but the first on the chopping block is
StorageDecl::getGetterType (and its three friends) which is now always exactly
just getGetter()->getType().
Swift SVN r12983
mostly to get the brokenness inherent in their current representation out
of my way.
The biggest part of this is that properties in protocols are now always
represented as Computed VarDecls. If you write "var x : Int" in a protocol,
you get an getter FuncDecl. If you write "var x : Int { get}" you get the same
thing. If you write "var x : Int { get set }" then you get a getter and setter
prototype associated with the vardecl.
This then readjusts the various hacks that sort of pass through such things
in SILGen and IRGen, so that we have the same level of hacky support for properties
in protocols.
From the functionality perspective, this enables the { get set } syntax described
in rdar://15827219, and means that "var x : Int" is uniformly treated as read-only
(it was treated as mutable in some cases before). Properties in protocols are
still quite broken though.
Swift SVN r12981
This patch:
- Changes sema to set the "IsDirectPropertyAccess" on MemberRefExprs
in inits/destructors that should be done directly because they are
on the local object.
- Removes the "SGF.AlwaysDirectStoredPropertyAccess" bool in SILGen,
which was the source of the problem above and was otherwise problematic.
This will get a bit simpler when -enable-new-objc-properties rolls out.
Swift SVN r12967
If all of the bindings in a pattern column are 'let' bindings, don't box the binding. If there is any 'var' in the column, conservatively fall back to binding a box. Factor out the logic for producing an initialization for a variable into an new emitInitializationForVarDecl method that SILGenPattern can use. Add a 'copyInto' method to RValue that can bind a copy of an rvalue to an Initialization.
This doesn't use Chris's new +0 ManagedValue optimization yet, so we end up with an extra copy_value when the value is bound that might still be avoidable.
Swift SVN r12903
- Strength reduce the interface to LogicalPathComponent::getMaterialized
to now just return a SILValue for the address. The full "Materialize"
structure hasn't been needed since MaterializeExpr got removed.
- Move 'struct Materialize' out of SILGen.h into SILGenLValues.cpp now
that it is only used for logical property materialization.
- Drop the dead 'loc' argument on DeallocStackCleanup. The location is
already specified when the cleanup is emitted.
Swift SVN r12827
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
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
move OverriddenDecl and usesObjCGetterAndSetter() up to it.
This allows usesObjCGetterAndSetter to subsume the logic
for subscript decls as well.
Swift SVN r12535
1) Revert my change to give DeclContext a dump method, it confuses the debugger.
2) Refactor SILGen::requiresObjCPropertyEntryPoints out to
VarDecl::usesObjCGetterAndSetter.
Swift SVN r12526
- constify the Initialization::getAddressOrNull/hasAddress functions.
- Teach the initialization logic that 'let' initializations can be
split into tuple subelements by address (i.e. i
getSubInitializationsForTuple works on them) when the let decl has
a backing memory allocation.
- Teach LetValueInitialization to produce a backing memory object
for address-only tuple arguments, since they are passed as multiple
SILArguments and need some place in memory to reassemble them.
The collection fixes a bad miscompilation where the RValue logic emitted
a temporary (through getSingleValue) which we then accidentally lifetime
extended for the duration of the argument. This led to bad things when
the temporary got destroyed too early.
Thanks to MichaelG for helping narrow down this problem, it initially looked
like a sil optimizer bug.
Swift SVN r12234
