This function creates a new scheduler with a specified number of threads and
immediately executes a task on it. The scheduler is configured to terminate
when the task dies. This is the minimum API necessary to enable blocking C
calls.
Added class support to the parser, prettyprinter, fold, and visit.
(See Issue 1726.)
This is WIP -- the test case is xfailed, and attempting to compile
it will error out in resolve.
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
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
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.
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
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.
Although the old version of GEP_tup_like was incorrect in some
cases, I do not believe we ever used it in an incorrect fashion.
In particular, it could go wrong with extended index sequences
like [0, 1, 3], but as near as I can tell we only ever use it
with short sequences like [0, i].
This commit allows patterns like:
alt x { some(_) { ... } none { } }
without the '.' after none. The parser suspends judgment about
whether a bare ident is a tag or a new bound variable; instead,
the resolver disambiguates.
This means that any code after resolution that pattern-matches on
patterns needs to call pat_util::normalize_pat, which consults
an environment to do this disambiguation.
In addition, local variables are no longer allowed to shadow
tag names, so this required changing some code (e.g. renaming
variables named "mut", and renaming ast::sub to subtract).
The parser currently accepts patterns with and without the '.'.
Once the compiler and libraries are changed, it will no longer
accept the '.'.
Addresses issue #1393.
For now disallow disr. values unless all variants use nullary
contractors (i.e. "enum-like").
Disr. values are now encoded in the crate metadata, but only when it
will differ from the inferred value based on the order.
