This involved adding 'copy' to more generics than I hoped, but an
experiment with making it implicit showed that that way lies madness --
unless enforced, you will not remember to mark functions that don't
copy as not requiring copyable kind.
Issue #1177
This makes it possible to omit the semicolon after the block, and will
cause the pretty-printer to properly print such calls (if
pretty-printing of blocks wasn't so broken). Block calls (with the
block outside of the parentheses) can now only occur at statement
level, and their value can not be used. When calling a block-style
function that returns a useful value, the block must be put insde the
parentheses.
Issue #1054
also repair various errors in the parser related to such blocks.
rename checked_blk to default_blk to reflect the fact that it
inherits its purity from the surrounding context.
There's no good reason to force them to be spilled anymore. Some
pieces of trans become more elegant this way, and less stack allocs
and load/stores are needed.
Issue #1021
This converts the AST fold into a resource that breaks it's own circular
reference (just a temporary workaround until GC), so that failure during fold
will unwind correctly.
Issue #936
We were only using it in a single place, and there for no discernable reason
(probably as part of the bare-fn-vals-are-not-copyable plan). It seems more
surprising than useful.
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.
