Although its not really needed. Without that fix, reported spans will
likely be bogus if the error is within the first couple of lines
(probable around 5) of that file. Thus, many of the compile-fail
tests will fail due to incorrect location.
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).
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.
