Under this scheme when parsing foo.rc the parser will also look for
foo.rs to fill in the crate-level module, and when evaluating a
directory module directive it will look for a .rs file with the
same name as the directory.
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
Previously, the parser would try to interpret this as a block call:
if true {} // No semicolon
{|i, am, a, block|};
Which, though unlikely, might come up in practice.
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.
Patch to error and fail instead of using all available memory
then crashing to detect the error condition of an unmatched
double quote before the end of a file.
I couldn't get it to show nice error messages, so this may not be
the ideal fix.
A test case for this situation has also been added.
It is now 1-based, rather than 0 based. (Seems more natural, and allows 0 to
be used to refer to self and maybe to closure.)
Also allows non-referenced args to be implicitly copied again.
Issue #918
- Loop bodies and resource constructors aren't allowed to have
trailing expressions anymore.
- An expression that ends* in a block without trailing expression can
can not be called, indexed, or subscripted.
- Only expression-statements that end* in a block without trailing
expression can omit their semicolon.
*) 'Ending in a trailing expression' is defined as being a block or
construct-ending-in-a-block (if, alt) that either ends in an
expression itself, or ends in another block-like expression that
has a trailing expression (by these same rules).
