forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 1
Bikeshed alt check
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 check
s:
- 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
inastencode
- various things in
tydecode
- 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 purityextern_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 aby_val
(I faked this by changing thedest
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 alocal_mem
thing in thellargs
table, but I'm not sure how that's guaranteed)
- 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)
- 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
anddriver::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 inliningfind_linkage_attrs
, which didn't really need to be a separate function, intofind_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 anexpr_fn_block
instead of a generalexpr
; this could be improved even further by changing the AST)
- Addressed by non-trivial refactoring (see send_map for an example)
- core::send_map (several)
- matches on
ast::expr_loop_body
andast::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
andtystr_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 actor
) (ctor_arity
andspecialize
in the same file too) -
check_const::check_item_recursion
(const must be bound to an item) -
trans::base::trans_rec
(expects anexpr_rec
to have aty_rec
type) -
trans::base::trans_expr::unrooted
:expr_rec
case requires that the dest is notby_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 asingle_result
, but I don't know how that's guaranteed) -
trans::base::trans_arg_expr
(ifret_flag
is asome
, then the expr must be aloop_body
, but it's hard to express this constraint) -
trans::base::trans_item
(depends on a table lookup and fails ifitem
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
andget_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 adef_id
and substs instead of at
might help
- in the last case, changing
-
trans::impl::trans_method_callee
(requires thatparam_substs
in the function context be non-none
); similarly,resolve_vtable_in_fn_ctxt
-
trans::impl::get_vtable
(complicated invariant involving a table lookup: iforigin
's id is not in the table, then it must be avtable_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)
- 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
(theVariant
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)