pprust::print_if does not anticipate evil

[jruderman]

If my fuzzer replaces the 'els' node with something other than an expr_if or expr_block, I get:

upcall fail 'non-exhaustive match failure', ../src/comp/syntax/print/pprust.rs:636

[marijnh]

You'll get that in several other places. Our ast structure accepts only those two forms in that position. Though other things are representable, they aren't proper rust asts.

[jruderman]

Maybe a
case(_) { fail "Invalid AST" }
would help the fuzzer distinguish between this kind of thing and actual bugs in the pretty-printer.

[marijnh]

I'd recommend rigging the fuzzer to simply not output such ASTs. You probably already have similar code to ensure only lvalues are output as the lhs of assign/move expressions.

[pcwalton]

How about just adding a constraint to the AST? We have refinement types after all (or are supposed to) :)

[brson]

Yeah, we should start adding constraints where it makes sense

[jruderman]

Will that change the fold signature, or will it make fold do a check/fail?

[brson]

It will make it impossible to construct an expr_if that contains the wrong kind of else expression. I think in practice the code that wants to do such a think would be forced to do an

if check (is_else_expr(e)) {
  ... build my expr_if ...
} else {
  ... try something different ...
}

[brson]

I realize that that didn't actually answer your question. I don't think it would change the fold signature, but would change the code that uses the fold.

[catamorphism]

We don't have constrained types, so "add a constraint to the AST" won't work yet. It's my next to-do, though!

[catamorphism]

(Assigning to myself so I can use this as a test case for constrained types once they're implemented)

[nikomatsakis]

Not relevant as of commit 41a21f0, which removed current incarnation of typestate.