* -g or --mode=user to create/use .cargo under $HOME
* -G or --mode=system to create/use .cargo under sysroot
* by default, `cargo` uses .cargo under current working directory
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.
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.
Now that core exports "option" as a synonym for option::t, search-and-
replace option::t with option.
The only place that still refers to option::t are the modules in libcore
that use option, because fixing this requires a new snapshot
(forthcoming).
All the files below had at least one instance of the ternary operator
present in the source. All have been changed to the equivalent
if/then/else expression.
Aligning the type parameters of the ifaces, impls, and methods
correctly in typeck is almost brain surgery. Seems to work now for
everything I threw at it, but might still break in other corner cases.
Issue #1227
Issue #828
This is not a full solution yet. To really get sane error messages,
we'll also have to guess the name to apply to literals, which seems
non-trivial.
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
It's proving too inflexible, so I'm ripping out the extra complexity
in the hope that regions will, at some point, provide something
similar.
Closes#918
