resolve has a few type definitions in it that are used, so I left
those and deleted everything else. Also, I switched rustdoc to use
resolve3 instead of the old resolve.
In a future commit I'll remove the type definitions entirely, as they're
just duplicates of types defined in resolve3.
In order to avoid a confusing use of the tcache, I added an extra
node ID field to trait refs. Now trait refs have a "ref ID" (the one
that resolve3 resolves) and an "impl ID" (the one that you look up
in the tcache to get the self type).
Closes#2434
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.
The old way was inconsistent---the head was unboxed but the
tail was boxed. This resulted in numerous needless copies and
also made the borrow check unhappy, because the head tended to be
stored in mutable memory.
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.
Necessary to resolve any type arguments in a ref to a parameterized
iface. This meant that, for example:
class A implements B<int> { ...
didn't work before, because the "int" in B's argument wasn't getting
visited, and thus wasn't getting resolved. Now it works.
Partially addresses Issue #2288, but I also want to check that class
ty params can appear as the type arguments to ifaces (for example,
class A<T> implements B<T> {...
should work.)
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)
As per Issue #1193. Closes#1193.
I had to rename a few variables ("info" and "epsilon") to avoid
clashing with in-scope constants, which is responsible for all the
changes other than resolve and issue-1193.rs.
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!
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
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
All field or method references within a class must begin with "self." now.
A bare reference to a field or method in the same class will no longer
typecheck.
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).
Allow writing self.f within a class that has a field f. Currently,
the compiler accepts either self.f or f. In a future commit I'll
require writing self.f and not f.
Not sure whether self.f() works if f is a method (making sure that
works next).
This change uses the same code for handling the "self" reference for
classes as is already used for impls/ifaces. This allows removing the
extra maybe_self_id argument (which was just for classes) to trans_closure
that I added before. I also rewrote the translation for class ctors so
that it doesn't generate new AST nodes (instead translating directly).
Also changed visit so that it visits class ctors correctly with visit_fn,
and changed typestate to not do return-checking when visiting a class ctor.
Something strange is happening to hash maps. I'm still investigating but
want to get my snapshot built in the meantime. (Problem only happened on
OS X.)
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.)
Cross-crate metadata for classes works well enough that programs with
classes in other crates compile successfully, but output wrong results.
Checking in work so far to avoid merge hassles. (Tests are xfailed.)
This makes it possible to move them between crates without confusion,
and to instantiate them at a point where the monomorphizing
substitutions are known.
Issue #1944
Programs using classes with fields only (no methods) compile and run,
as long as nothing refers to a class in a different crate (todo).
Also changed the AST representation of classes to have a separate
record for constructor info (instead of inlining the fields in the
item_class node), and fixed up spans and pretty-printing for
classes.
