Also shuffles around the organization of numeric literals and types,
separating by int/uint/float instead of machine-vs-non-machine types.
This simplifies some code.
Closes#974Closes#1252
It's proving too inflexible, so I'm ripping out the extra complexity
in the hope that regions will, at some point, provide something
similar.
Closes#918
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 goes before a snapshot, so that subsequenct patches can make the
transition without breaking the build. Disables kind checking pass, makes
parser accept both new and old-style kind annotation.
Issue #1177
You almost never want a function with pinned type params. For
types, objects, resources, and tags, pinned types are actually often
more sane. For most of these, shared rarely makes sense. Only tricky
case is objs -- you'll have to think about the kinds you want there.
Issue #1076
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
Trans has been assuming that tag node id's are unique across crates and they
are not so, depending on which way the wind is blowing, it would choose to use
a crate-local tag variant instead of the correct one from std.
No test case since I can't come up with a reliable one that compiles in a
reasonable amount of time.
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.
Upvars are now marked with def_upvar throughout, not just when going
through freevars::lookup_def. This makes things less error-prone. One
thing to watch out for is that def_upvar is used in `for each` bodies
too, when they refer to a local outside the body.
Having it in the alias pass was slightly more efficient (finding
expression roots has to be done in both passes), but further muddled
up the already complex alias checker.
Also factors out some duplication in the mutability-checking code.
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.
