Skip to content
catamorphism edited this page Aug 24, 2012 · 25 revisions

This is a compendium of match check expressions in libraries and rustc. My goal is to figure out how many there are of each kinds. I'm guessing there will be the following kinds of match checks:

  1. User input (we can't really do anything about this except add an error case. Time format strings are an example; anything involving parsing, basically.)
  • std::time::strftime
  • test cases in core::comm, core::run, core::str, std::ebml, std::getopts
  • serialization::deserialize_option
  • code generated by autoserialize
  • read_vtable_origin in astencode
  • various things in tydecode
  1. Subsets of enums (hopefully will be addressed in the future with case classes / refinement types)
  • trans::base::trans_lval (type of a unary operation -- would be great if typeck could produce something with a refined type...)
  • std::list::head (great argument for refinements)
  • encoder::purity_static_method_family (we currently can't encode that static methods can never have purity extern_fn)
  • trans::base::trans_lval (can't encode the refinement on the type of a unary operand)
  • trans::base::trans_rec -- dest may not be a by_val (I faked this by changing the dest argument to an option that represents the subset we want)
    • In the same function, the expr's type must be a record type (but this depends on a table lookup)
  • trans::base::trans_enum_variant (relies on the invariant that its argument is bound to a local_mem thing in the llargs table, but I'm not sure how that's guaranteed)
  1. Difficult stuff (example: match len % 3 { ... where you know where will only be three cases. We will probably never have a fancy enough type system to make this exhaustive)
  • std::base64 impl of to_base64 for ~[u8]
  • const_eval::eval_const_expr (relies on type soundness)
  1. Easily rewritten (for example, when you only handle a specific variant and you can just pass its components instead)
  • trans::base::make_mono_id (a vec of mono_ids all constructed with mono_precise gets consumed immediately)
  • trans::base::llvm_type_name (only called on obvious enum and class types, so just pass the def_id and substs)
  • core::bool::from_str (already had a _ case!)
  • code dealing with expr_log things (made log_level an enum instead of an int)
  • matching on optimization levels in back::link and driver::driver (make optimization level an enum)
  • Log levels in expr_log (make it an enum rather than a uint)
  • syntax::attrs::find_linkage_metas (addressed by inlining find_linkage_attrs, which didn't really need to be a separate function, into find_linkage_metas)
  • trans::base::trans_block_cleanups (take a list of cleanups instead of a block)
  • trans::base::trans_loop_body (take the contents of an expr_fn_block instead of a general expr; this could be improved even further by changing the AST)
  1. Addressed by non-trivial refactoring (see send_map for an example)
  • core::send_map (several)
  • matches on ast::expr_loop_body and ast::expr_do_body things (refactoring the AST to eliminate junk -- this could have been also addressed with subsets-of-enums)
  • lint::check_fn -- there's currently no constraint that a function must have a function type (in the type context)
  • only some combinations of types are supported in a cast in middle::trans::consts
  • encoder::encode_info_for_items: item might map to a non-item node in the AST map
  • attr_pass and tystr_pass in rustdoc: lots of table lookups where an ID might map to the wrong type of item. Could address this by having more maps.
  • check_alt::check_exhaustive: also some table lookups (dependency between a thing's type and the form of a ctor) (ctor_arity and specialize in the same file too)
  • check_const::check_item_recursion (const must be bound to an item)
  • trans::base::trans_rec (expects an expr_rec to have a ty_rec type)
  • trans::base::trans_expr::unrooted: expr_rec case requires that the dest is not by_val. I don't know how this invariant is guaranteed.
  • trans::alt::extract_variant_args (depends on table lookup: pattern ID must have an enum type)
  • trans::alt::compile_submatch (table lookup: in one case, trans_opt is constrained to return a single_result, but I don't know how that's guaranteed)
  • trans::base::trans_arg_expr (if ret_flag is a some, then the expr must be a loop_body, but it's hard to express this constraint)
  • trans::base::trans_item (depends on a table lookup and fails if item isn't bound to an item in the AST map; might want to split up the AST map to avoid checks like this) (item_path and get_item_val, crate_ctxt_to_encode_parms, impl::trans_static_method_callee, impl::method_with_name, typeck::check::method::{report_static_candidate, ty_from_did}, typeck::check::vtable::{fixup_substs, lookup_vtable, connect_trait_tps} have similar checks)
    • in the last case, changing bound_trait to take a def_id and substs instead of a t might help
  • trans::impl::trans_method_callee (requires that param_substs in the function context be non-none); similarly, resolve_vtable_in_fn_ctxt
  • trans::impl::get_vtable (complicated invariant involving a table lookup: if origin's id is not in the table, then it must be a vtable_static)
  • ty::get_field (not sure how we know that we only call this when the field is in the list)
  • typeck::check::check_bare_fn (depends on a table lookup)
  1. Results of metadata lookup (not much we can do here except add an error case, as in 1.)
  • trans::base::monomorphic_fn::maybe_instantiate_inline
  • decoder::item_to_def_like (the Variant case; item_parent_item returns an option)
  • get_trait_methods (doc for method might have an item_family that's not a purity value)
  • decoder::family_to_visibility (similar)
  • trans::base::maybe_instantiate_inline, found_parent case (item could have a non-enum parent)

All Categories:

Clone this wiki locally