This patch supports the syntax
unchecked {
...
}
to disable purity checking within a block. Presumably it will only be
used within a declared "pure fn". However, there is no checking that it
doesn't occur elsewhere, and it would be harmless for it to do so.
I went with Lindsey's suggestion for the syntax, but it's subject to
change.
This allows you to write code that uses predicates that call arbitrary
Rust functions, but you must declare your intentions by wrapping it in
an unchecked { ... } block. The test case run-pass/unchecked-predicates.rs
demonstrates how to do that.
The syntax is
alt x {
mypat where mycond { ... }
}
The condition may refer to any of the variables bound by the pattern.
When a guard fails, pattern-matching continues with the next pattern.
Closes#857
This makes it easier for the caller to optimize the take/drop away for
temporary values, and opens up new possibilities for alias handling.
Breaks tail calls.
This actually basically makes things worse, since we get less nice
type system guarentees but it will make doing type inferred blocks a
fair deal less painful. I'm not /really/ happy about this...
You can now say
let {bcx, val} = some_result_returner();
Similar for loop variables. Assigning to such variables is not safe
yet. Function arguments also remain a TODO.
This adds parser support and most of the machinery for
auto x = 10, y = 20;
However, the above still goes wrong somewhere in typestate, causing
the state checker to believe only the last variable in the list is
initialized after the statement.
Tim, if you have a moment, could you go over the changes to the tstate
code in this patch and see where I'm going wrong?
Multi-var-decls without the typestate extension
Add a loop
Programs with constrained types now parse and typecheck, but
typestate doesn't check them specially, so the one relevant test
case so far is XFAILed.
Also rewrote all of the constraint-related data structures in the
process (again), for some reason. I got rid of a superfluous
data structure in the context that was mapping front-end constraints
to resolved constraints, instead handling constraints in the same
way in which everything else gets resolved.
This prevents any defined main function from colliding with the one
synthesized for the test runner. This is not the best solution since it
doesn't compile a function the user defined, but I don't think it's likely to
be a problem in the near term.
