Remove disr_val from ast::variant_ and always use ty::variant_info
when the value is needed. Move what was done during parsing into
other passes, primary typeck.rs. This move also correctly type checks
the disr. value expression; thus, fixing rustc --pretty=typed when
disr. values are used.
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).
Use ifaces instead of objs, stop wrapping everything in two (or three)
layers of no-value-added indirection, and remove some of the more
pointless/outdated idioms from the code.
Addresses issue #1393.
For now disallow disr. values unless all variants use nullary
contractors (i.e. "enum-like").
Disr. values are now encoded in the crate metadata, but only when it
will differ from the inferred value based on the order.
Now, if you have a tag named "foo", a variable declaration like
"let foo..." is illegal. This change makes it possible to eliminate
the '.' after a nullary tag pattern in an alt (but I'll be doing
that in a future commit) -- as now it's always obvious whether a
name refers to a tag or a new declared variable.
resolve implements this change -- all the other changes are just to
get rid of existing code that declares variables that shadow tag
names.
The (temporary) syntax is
iface seq<T> {
fn len() -> uint;
fn iter(f: block(T));
}
// The 'blah<T>' can be left of to default the name of the
// impl to seq<T>. The 'of seq<T>' can be left off when
// not implementing a named interface.
impl blah<T> of seq<T> for [T] {
fn len() -> uint { vec::len(self) }
fn iter(f: block(T)) { for x in self { f(x); } }
}
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.
I think it should undefined to have multiple modules that link in the same
library, but provide different link arguments. Unfortunately we don't track
link_args by module -- they are just appended as discovered into the crate
store -- but for now, it should be an error to provide link_args on a module
that's already been included (with or without link_args).
