In this commit:
* Change the lit_int_unsuffixed AST node to not carry a type, since
it doesn't need one
* Don't print "(unsuffixed)" when pretty-printing unsuffixed integer
literals
* Just print "I" instead of "(integral)" for integral type variables
* Set up trans to use the information that will be gathered during
typeck to construct the appropriate constants for unsuffixed int
literals
* Add logic for handling int_ty_sets in typeck::infer
* Clean up unnecessary code in typeck::infer
* Add missing mk_ functions to middle::ty
* Add ty_var_integral to a few of the type utility functions it was
missing from in middle::ty
It was a little hard for me to believe, but it seems that re-exporting
an impl doesn't work at a, because encoder::encode_info_for_mod requires
that all the impls in the current module's impl map be local (that is,
bound to a value in the current crate's item map). Fixed it.
Closes#2414.
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
- we now distinguish bound/free parameters (see region-param
test case for why this is necessary)
- we also track bounds on region variables
- also, restructure fold_ty() to have multiple variants without
duplication instead of one overloaded folder. This also allows
for using block functions.
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).
1. Enforce mutability declarations on class fields. Don't allow any
mutation of class fields not declared as mutable (except inside the
constructor).
2. Handle classes correctly in shape (treat classes like records).
