It is now no longer needed to have a ty::ctxt to get at the contents
of a ty::t. The straight-forward approach of doing this, simply making
ty::t a box type, unfortunately killed our compiler performance (~15%
slower) through refcounting cost. Thus, this patch now represents
ty::t as an unsafe pointer, assuming that the ty::ctxt, which holds
these boxes alive, outlives any uses of the ty::t values. In the
current compiler this trivially holds, but it is does of course add a
new potential pitfall.
ty::get takes a ty::t and returns a boxed representation of the type.
I've changed calls to ty::struct(X) to do ty::get(X).struct. Type
structs are full of vectors, and copying them every time we wanted to
access them was a bit of a cost.
This allows a 'Name:' to appear in front of an iface declaration's
name, which will cause 'Name' to refer to the self type (with the same
number of type parameters as the iface has) in the method signatures
of the iface. For example:
iface F: functor<A> {
fn fmap<B>(f: fn(A) -> B) -> F<B>;
}
Issue #1718
The direct motivation for this was that the monomorphizer needs to be
able to generate sane symbols for random items. The typechecker can
probably also use this in the future to provide more useful error
messages.
Almost all of the vec functions that predicates don't have a
corresponding function that takes a single element, so this
commit renames the common fn usecase to be the default.
Removes a bunch of (eventually) unused arguments. Makes span passing to debuginfo
explicit, instead of relying on the (usually incorrect) spans held in the contexts.
Closes#1439
This is not my ideal way of going about things. I'd prefer not
to have expressions typed as fn*(), for example, but I couldn't
get that to work together with inferring the modes of arguments
and other corner cases.
Although the old version of GEP_tup_like was incorrect in some
cases, I do not believe we ever used it in an incorrect fashion.
In particular, it could go wrong with extended index sequences
like [0, 1, 3], but as near as I can tell we only ever use it
with short sequences like [0, i].
Rather, it is now a struct where properties like opts are accessed
directly, and the error-reporting methods are part of a static impl
(with the same name as the type).
Also shuffles around the organization of numeric literals and types,
separating by int/uint/float instead of machine-vs-non-machine types.
This simplifies some code.
Closes#974Closes#1252
