Classes with dtors should compile now. Haven't yet tested
whether they actually run correctly.
Beginnings of support for #2295, though that won't be done until
there's more test cases and resources are removed.
a module
See the test case I added (issue-2316-c) for a concrete example.
issue-2316 also contains the originally reported test case. resolve
was using bitwise or instead of logical or when checking exports,
resulting in excessively eager evaluation. A one-line fix that took
six hours to isolate ;-)
- paths can now take region parameters, replacing the dirty hack
I was doing before of abusing vstores. vstores are now a bit
of a hack though.
- fix various small bugs:
- we never checked that iface types were compatible when casting
to an iface with `as`
- we allowed nonsense like int<int>
- and more! (actually that may be it)
Introduce syntax like:
iface animal { ... }
class cat implements animal { ... }
to allow classes to implement ifaces. Casting classes to ifaces
is *not* yet supported. ifaces that a class implements are not
yet included in metadata.
The syntax is subject to change, and may go away completely if we
decide to use duck typing to relate classes with ifaces (see
http://smallcultfollowing.com/babysteps/blog/2012/04/10/declared-vs-duckish-typing/ )
Classes can have ty params now. So can methods inside classes.
That was probably true before, but now it should still work if you
call methods in a class that's defined in a different crate. Yay!
`use` statement may introduce an crate name alias. This patch always
uses the link attrbute "name" as the crate's name when building the
crate map.
Closes#1706
get_with_default (nee from_maybe) => get_default
with_option (nee maybe) => map_default
with_option_do (nee may) => iter
As per discussion of 21be1379d5
Most could use the each method, but because of the hack used to
disambiguate old- and new-style loops, some had to use vec::each.
(This hack will go away soon.)
Issue #1619
