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].
This commit allows patterns like:
alt x { some(_) { ... } none { } }
without the '.' after none. The parser suspends judgment about
whether a bare ident is a tag or a new bound variable; instead,
the resolver disambiguates.
This means that any code after resolution that pattern-matches on
patterns needs to call pat_util::normalize_pat, which consults
an environment to do this disambiguation.
In addition, local variables are no longer allowed to shadow
tag names, so this required changing some code (e.g. renaming
variables named "mut", and renaming ast::sub to subtract).
The parser currently accepts patterns with and without the '.'.
Once the compiler and libraries are changed, it will no longer
accept the '.'.
This fixes issues #843 and #1546. The cost of an upcall is
unfortunate, though. I assume there must be a way to simply manually
compute the pointer or size, using something akin to the formula in
`align_to` in `rust_util.h`. I could not get this to work,
unfortunately.
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.
For some reason, wildcard patterns were never getting type parameter
substitutions attached. This would cause an assertion failure when
checking a wildcard pattern that matches against a tag with
polymorphic type (not sure why this didn't come up before). Fixed it.
(The diff and test case may be easier to understand than this note
:P)
Closes#1503.
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).
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.