Irritatingly, class dtors have a different type from resource
dtors (because class dtors have a self argument), and the monomorphic
case wasn't reflecting that. Fixed.
These were getting resolved too early, when they were still
unconstrained by the rest of the typing context. Waiting a bit longer
to resolve them gives the rest of the typing context a chance to come
into play, so that they don't default to `int`.
Some code that handles unary and binary exprs' callee IDs was
forgetting to handle the index expr case (since calls to
user-defined index operators also have callee IDs). This was
manifesting as an ICE in trans because when monomorphizing a
function that had one of these operators in it (an index into a
dvec, in the test case), the callee ID would be unbound to a type.
Fixed it. Closes#2631.
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
There was a FIXME noting that ty::enum_variants and typeck::check::
check_enum_variants both call eval_const_expr. I tried refactoring the
code so that check_enum_variants does all the work and enum_variants
just looks up cached results, but this turned out not to be easy because
several ty functions call enum_variants and it might get invoked on an
enum before that enum item has been typechecked. Instead, I just made
check_enum_variants update the enum_var_cache so that enum_variants
will never call eval_const_expr twice on the same const.
