Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Context archetypes and opened existential archetypes differ in a number of details, and this simplifies the overlapping storage of the kind-specific fields. This should be NFC; for now, this doesn't change the interface of ArchetypeType, but should allow some refinements of how the special handling of certain archetypes are handled.
A few utility methods would bypass computing the TypeInfo for a tuple,
but they were only used in assertions or used in places where I can't
imagine tuples coming up often enough for it to matter.
- The DeclContext versions of these methods have equivalents
on the DeclContext class; use them instead.
- The GenericEnvironment versions of these methods are now
static methods on the GenericEnvironment class. Note that
these are not made redundant by the instance methods on
GenericEnvironment, since the static methods can also be
called with a null GenericEnvironment, in which case they
just assert that the type is fully concrete.
- Remove some unnecessary #includes of ArchetypeBuilder.h
and GenericEnvironment.h. Now changes to these files
result in a lot less recompilation.
Rather than directly using the ArchetypeBuilder associated with a
canonical generic signature, use a canonical GenericEnvironment
associated with that canonical generic signature. This has a few
benefits:
* It's cleaner to not have IRGen working with archetype builders;
GenericEnvironment is the right abstraction for mapping between
dependent types and archetypes for a specific context.
* It helps us separate the archetype builder from a *specific*
set of archetypes. This is an ongoing refactor that is intended to
allow us to re-use archetype builders across different generic
environments.
As part of this, ArchetypeBuilder::substDependentType() has gone away
in favor of GenericEnvironment::mapTypeIntoContext().
... by deleting some dead code. Thanks to John McCall for noting
that this entire codepath is a vestigal remnant from the days
of IRGenning directly from AST.
Fixes <rdar://problem/18406224>.
Swift SVN r31242
The isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
This time, fix a paste-o that caused SILBlockStorageTypes to get replaced with SILBoxTypes during type substitution. Oops.
Swift SVN r29489
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
Swift SVN r29474
Modeling builtins as first-class function values doesn't really make sense because there's no real function value to emit, and modeling them this way complicates passes that work with builtins because they have to invent function types for builtin invocations. It's much more straightforward to have a single instruction that references the builtin by ID, along with the type information for the necessary values, type parameters, and results, so add a new "builtin" instruction that directly represents a builtin invocation. NFC yet.
Swift SVN r22690
If a type has to be passed or returned resiliently, it
will necessarily be passed indirectly, which is already
represented in SILFunctionType. There is no need to
represent this as a separate channel of information.
NFC. Also fixes a problem where the signature cache
for ExtraData::Block was writing past the end of an
array (but into the storage for an adjacent array
which was fortunately never used).
ExtraData should also disappear as a concept, but we're
still relying on that for existential protocol witnesses.
Swift SVN r21548
dynamicCastClass assumes that the destination type is a
Swift class type.
dynamicCastObjCClass assumes that the destination type is
an ObjC class type (represented as ObjC metadata, not type
metadata).
dynamicCastUnknownClass assumes only that the destination
type is some kind of class.
Swift SVN r18776
When origResultType Array<τ_0_0>.IndexType is substituted to Int,
differsByAbstractionInMemory should return false instead of crashing
in llvm_unreachable.
rdar://16809311
Swift SVN r17810
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
Blocks need to be born on the stack, so we need a way to represent that on-stack storage. @block_storage T will represent the layout of a block that contains storage for a capture of type T.
Swift SVN r16355
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
- 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
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
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
IRGen type conversion is invariant with respect to archetypes with the same set of constraints, so instead of redundantly generating a TypeInfo object and IR type for Optional<T> for every T everywhere, key TypeInfo objects using an "exemplar type" that we form using a folding set to collapse together archetypes with the same class-ness, superclass constraint, and protocol constraints.
This is a nice memory and IR size optimization, but will be essential for correctness when lowering interface types, because there is no unique context to ground a dependent type, and we need to lower the same generic parameter with the same context requirements to the same type whenever we instantiate it in order for the IR to type-check.
In this revision, we profile the nested archetypes of each recursively, which I neglected to take into account originally in r12112, causing failures when archetypes that differed by associated type constraints were incorrectly collapsed.
Swift SVN r12116
IRGen type conversion is invariant with respect to archetypes with the same set of constraints, so instead of redundantly generating a TypeInfo object and IR type for Optional<T> for every T everywhere, key TypeInfo objects using an "exemplar type" that we form using a folding set to collapse together archetypes with the same class-ness, superclass constraint, and protocol constraints.
This is a nice memory and IR size optimization, but will be essential for correctness when lowering interface types, because there is no unique context to ground a dependent type, and we need to lower the same generic parameter with the same context requirements to the same type whenever we instantiate it in order for the IR to type-check.
Swift SVN r12112
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
Function abstraction differences should have been handled by SILGen. Do a sanity check to make sure the conventions line up, and then assume that the function types are compatible.
Swift SVN r11620
Use the 'thin' bit set by SIL to decide whether a metatype lowers to an empty type or not. In GenPoly we still need to accommodate unlowered metatypes to keep protocol witnesses limping along; hopefully that code can be killed soon. With this change we now lower @cc(witness_method) consistently for static methods.
Swift SVN r11535
