Closes#1728
Comments out a section of debuginfo.rs. This code was already broken
(only being called when --xg was passed, and only working on trivial
programs).
In addition add information about the macro doing the expansion, and
move the printing of the expansion backtrace from codemap::span_to_str
to the diagnostic code. The backtrace is now more verbose and
includes information on the macro doing the expansion, in addition to
the expansion site.
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).
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.
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.
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 '.'.
Remove disr_val from ast::variant_ and always use ty::variant_info
when the value is needed. Move what was done during parsing into
other passes, primary typeck.rs. This move also correctly type checks
the disr. value expression; thus, fixing rustc --pretty=typed when
disr. values are used.
See src/test/run-pass/nested-patterns.rs for some examples. The syntax is
boundvar@subpattern
Which will match the subpattern as usual, but also bind boundvar to the
whole matched value.
Closes#838
Also shuffles around the organization of numeric literals and types,
separating by int/uint/float instead of machine-vs-non-machine types.
This simplifies some code.
Closes#974Closes#1252
It's proving too inflexible, so I'm ripping out the extra complexity
in the hope that regions will, at some point, provide something
similar.
Closes#918
This involved adding 'copy' to more generics than I hoped, but an
experiment with making it implicit showed that that way lies madness --
unless enforced, you will not remember to mark functions that don't
copy as not requiring copyable kind.
Issue #1177
This goes before a snapshot, so that subsequenct patches can make the
transition without breaking the build. Disables kind checking pass, makes
parser accept both new and old-style kind annotation.
Issue #1177
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
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
Trans has been assuming that tag node id's are unique across crates and they
are not so, depending on which way the wind is blowing, it would choose to use
a crate-local tag variant instead of the correct one from std.
No test case since I can't come up with a reliable one that compiles in a
reasonable amount of time.
