in with the new!
Random notes:
1. I had to XFAIL 4 IRGen tests; I'll file radars on them.
2. I preserved SliceStringByte and renamed it StringByteData because
it has some String-specific functionality.
3. There's a small IRGen patch included which fixes a couple of runtime
failures involving generic array new.
Swift SVN r2644
In particular, prepare for storing real v-table-like information
in the heap metadata. Give the metadata object proper linkage
and emit it as part of emitting the class.
Adjust the manglings of constructors and destructors while I'm
at it.
Swift SVN r2628
generation from an expression that has not been type-checked. One can
see the constraints introduced by an expression by using
:dump_constraints <expression>
within the REPL. We're still missing several major pieces of
constraint generation:
- We don't yet "open up" references to polymorphic types
- We don't print out the child constraint systems in the dump, so
it's not at all obvious what happens within overloading (and I'm not
convinced I like my representation anyway)
- There are no tests whatsoever
- Member constraints are still very, very weird
Swift SVN r2624
Builtin.ObjectPointer, and Builtin.RawPointer. I don't really like the way
these builtins are defined (specifically, the part where messing up
gives a mysterious IRGen error), but it's workable. <rdar://problem/11976323>.
Swift SVN r2585
checker. There are a few related sets of changes here:
- Generic parameter lists have a link to their "outer" generic
parameter lists, so its easy to establish the full generic context
of an entity.
- Bound and unbound generic types now carry a parent type, so that
we distinguish between, e.g., X<Int>.Inner<Int> and
X<Double>.Inner<Int>. Deduction, substitution, canonicalization,
etc. cope with the parent type.
- Opening of polymorphic types now handles multiple levels of
generic parameters when needed (e.g., when we're substituting into
the base).
Note that the generics module implied by this representation restricts
what one can do with requirements clauses in nested generics. For
example, one cannot add requirements to outer generic parameters or
their associated types, e.g., this is ill-formed:
struct X<T : Range> {
func f<U requires T.Element : Range>() {}
}
The restriction has some precedent (e.g., in C#), but could be
loosened by rearchitecting how we handle archetypes in nested
generics. The current approach is more straightforward.
Swift SVN r2568
metric to decide whether a dtor is side-effect free. This will be improved later
(to make it more aggressive), but is enough to get us to optimize away maxtest
from rdar://11542743 again, thus resolving rdar://11939216
Swift SVN r2559
a lot closer to successfully emitting the polymorphic-min-over-ranges
example; the main blocker right now seems to be that the witness
for a static member function is not, in fact, a static member
function at al, but a freestanding function. That's legitimate,
but it probably needs some shepherding through the witness
system.
Swift SVN r2532
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
when turning integer constants into floating-point values.
Teach IR-gen to fold stdlib convertFromIntegerLiteral and
convertFromFloatLiteral calls.
Update a bunch of tests.
Swift SVN r2485
in SpecializeExpr, so that we have complete substitution and
protocol-conformance information. On the IR generation side, pass
witness tables for all of the archetypes (again, including derived
archetypes) into generic functions, so that we have witness tables for
all of the associated types.
There are at least two major issues:
(1) This is a terribly inefficient way to pass witness tables for
associated types. The witness tables for associated types should be
accessible via the witness tables of their parent. However, we need
more information in the ASTs here, because there may be additional
witness tables that will need to be passed for requirements that are
placed on the associated type by the generic function itself.
(2) Something about my test triggers a void/non-void verification failure
in the witness build for an instance function whose abstracted form
returns an associated type archetype and whose concrete form returns
an empty struct. See the FIXME in the test.
Swift SVN r2464
in a digit. This penalizes the manglings of things using
builtin types but is kinder to the manglings of tuples.
Also, invent a not-unreasonable mangling for generic function
types and archtypes within them.
Swift SVN r2461
