Now that core exports "option" as a synonym for option::t, search-and-
replace option::t with option.
The only place that still refers to option::t are the modules in libcore
that use option, because fixing this requires a new snapshot
(forthcoming).
Since item_consts can't refer to or modify local variables, they
don't participate in typestate and thus get empty pre and
postconditions by default.
Closes#1660
All the files below had at least one instance of the ternary operator
present in the source. All have been changed to the equivalent
if/then/else expression.
3 tests, pretty/block-disambig.rs, run-pass/operator-overloading.rs,
and run-pass/weird-exprs.rs, all included the ternary operator. These
were changed to use the if-then-else construct instead.
2 tests, run-pass/block-arg-in-ternary.rs and run-pass/ternary.rs, were
only there because of the ternary operator, and were removed.
The methods used to implement operators now simply use
the name of the operator itself, except for unary -, which is called
min to not clash with binary -. Index is called [].
Closes#1520
When no built-in interpretation is found for one of the operators
mentioned below, the typechecker will try to turn it into a method
call with the name written next to it. For binary operators, the
method will be called on the LHS with the RHS as only parameter.
Binary:
+ op_add
- op_sub
* op_mul
/ op_div
% op_rem
& op_and
| op_or
^ op_xor
<< op_shift_left
>> op_shift_right
>>> op_ashift_right
Unary:
- op_neg
! op_not
Overloading of the indexing ([]) operator isn't finished yet.
Issue #1520
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.
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.
