This comes with a terminology change. All linkage-symbols are 'extern'
now, including rust syms in other crates. Some extern ABIs are
merely "foreign". The term "native" is retired, not clear/useful.
What was "crust" is now "extern" applied to a _definition_. This
is a bit of an overloading, but should be unambiguous: it means
that the definition should be made available to some non-rust ABI.
Issue 2526 showed a test case where a library exported only a type
that was a synonym for a class. Because the class's destructor wasn't
getting marked as reachable, its linkage was wrongly getting set to
"internal". The solution is for reachability to traverse types.
Closes#2526.
Reachability was considering nested items to be unreachable, which
was causing the bug in #2383. Once I fixed that, I also had to make
impl::make_impl_vtable instantiate methods where necessary, before
calling monomorphic_fn.
Closes#2383
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.
- 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/ )
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
from_maybe => get_with_default
maybe => with_option
may => with_option_do
I know these names are kind of ridiculous, but it's the best I could think of.
Feel free to bikeshed. Closes#2081
Allow writing self.f() within a class that has a method f. In a future
commit, this syntax will be required. For now, you can write either
self.f() or f().
I added a "privacy" field to all methods (whether class methods or not),
which allowed me to refactor the AST somewhat (getting rid of the
class_item type; now there's just class_member).
In particular, use the ast::method type to represent a class method,
and try to reuse as much iface code as possible. (This makes sense now
since I'll be allowing polymorphic class methods.)
