Allow expanding a tuple type T in a list of types with ..T.
#10769
Conversation
|
You should add some tests for the success cases as well. (I only see failure case tests in your current sketches.) Such tests would enable you to illustrate the use cases you have in mind. Of course, you should put the tests into pull request. (I'd like them as a separate commit but I think different people have different tastes when it comes to that.) |
|
@pnkfelix I've updated the tests gist since then, but I don't have many real use cases, because there is no way to express that a generic type parameter must be a tuple (so nothing function-related, like tuple structs or enum variants, works), that will come in the last step (the actual variadicity, That said, there are a couple of problems I would like to address at this moment: the lack of a span for |
| @@ -311,7 +311,8 @@ fn enc_sty(w: @mut MemWriter, cx: @ctxt, st: &ty::sty) { | |||
| ty::ty_infer(_) => { | |||
| cx.diag.handler().bug("Cannot encode inference variable types"); | |||
| } | |||
| ty::ty_param(param_ty {idx: id, def_id: did}) => { | |||
| ty::ty_param(expand, param_ty {idx: id, def_id: did}) => { | |||
| assert!(!expand); // FIXME(eddyb) #10769 what to do here? | |||
There was a problem hiding this comment.
These asserts at least have an error message (i.e. assert!(!expand, "encoding tuple expanding type parameter") or something), but would preferable call one of the .bug or .span_bug (or maybe even the unimpl ones?) methods on cx.tcx.sess rather than just having plain assert (so that users have some idea of what piece of code is causing the ICE).
Unless of course you can absolutely guarantee that it will never be hit.
There was a problem hiding this comment.
How about this:
if expand {
tcx.sess.bug(format!(
"found ty_param with expand=true `{}` in ty::hash_crate_independent",
ty_to_str(tcx, t)));
}There was a problem hiding this comment.
I think it would be worth actually saying the .. bit, since this error message could be user facing and, also, describing the actual internal state/details isn't particularly useful: as long as the message is vaguely unique, it takes 15 seconds with git grep to find the source location, and the failure condition is super simple and obvious from the source (i.e. the fact that we're emitting this implies that expand is true, if the condition was something like some_integer % 2 == 0 then printing the value would be useful).
There was a problem hiding this comment.
(@eddyb reminded me that ty_to_str includes the .. on IRC.)
|
I want to read this over before it lands. |
|
@eddyb, needs a rebase |
|
Closing this due to inactivity, but feel free to reopen with an update! |
add lint `manual_next_back` changelog: [`manual_next_back`]: checks for manual reverse iteration (`.rev().next()`) of a `DoubleEndedIterator` fixes rust-lang#10274
First part in implementing #10124,
..TwithTa tuple type, with only one structural change tomiddle::ty.cc @nikomatsakis @pnkfelix @pcwalton