This involved changing the prototype for the callbacks to thread the
span though. A wrapper function, fold::wrap, can be used to wrap the
old style callbacks.
This correctly fixes issue #1362.
chpos/byte_pos are now the offsets within a particular file, but
rather the offsets within a virtual file with is formed by combing all
of the modules within a crate. Thus, resetting them to 0 causes an
overlap and hence, bogus source locations.
Fix#1362 by moving chpos/byte_pos to parse_sess so that
new_parser_from_source_str has access to them and hence can chose an
initial value that is not already been used in the crate.
Note that the trigger for bug 1361 was that syntax/ext/expand.rs calls
parse_expr_from_source_str (which calls new_parser_from_source_str)
using the same codemap as the current crate (and hence causing overlap
with files in the crate as new_parser_from_source_str resets the
chpos/byte_pos to 0).
Need a better fix, right now it is just causing even more confusion,
for example in issue #1448 and #1387.
This reverts commit 1e4de333740690357a8f58883c5c69bf58be1424.
Check that in export foo{}, foo is an enum type, and that in export
foo{bar, quux}, foo is an enum type and bar and quux are variants belonging
to foo.
See issue 1426 for details. Now, the semantics of "export t;" where t is a tag are
to export all of t's variants as well. "export t{};" exports t but not its
variants, while "export t{a, b, c};" exports only variants a, b, c of t.
To do:
- documentation
- there's currently no checking that a, b, c are actually variants of t in the
above example
- there's also no checking that t is an enum type, in the second two examples above
- change the modules listed in issue 1426 that should have the old export
semantics to use the t{} syntax
I deleted the test export-no-tag-variants since we're doing the opposite now,
and other tests cover the same behavior.
Support Lenny222's proposed syntax for exporting a tag without
its variants, or selected tags from a variant, in the AST and parser.
No support further down the line yet. Tests are xfailed.
Previously, typestate would conclude that this function was
correctly diverging:
fn f() -> ! { ret; fail; }
even though it always returns to the caller. It wasn't handling the
i_diverge and i_return bits correctly in the fail case. Fixed it.
Closes#897
typestate was using the enclosing function ID for the "this function
returns" constraint, which meant confusion and panic in the case
where a predicate p includes "check p()". Fixed it to use a fresh
ID.
Closes#933
The code in Issue 948 was causing typestate to diverge because
it was using the prestate for the whole expression -- not the post-
state for the fields list -- as the prestate for the record base
expression. Fixed.
Closes#948
This is not my ideal way of going about things. I'd prefer not
to have expressions typed as fn*(), for example, but I couldn't
get that to work together with inferring the modes of arguments
and other corner cases.
