It appears that using deriving_eq/auto_encode on ASTs bumps up against the "gee this looks like infinite unfolding" limit of 10 in monomorphization. Increasing it to 30 seems to solve this problem for me....
Also, commenting and a few renames.
This patch series is doing a couple things with the ultimate goal of removing `#[allow(vecs_implicitly_copyable)]`, although I'm not quite there yet. The main change is passing around `@~str`s in most places, and using `ref`s in others. As far as I could tell, there are no performance changes with these patches, and all the tests pass on my mac.
r? @graydon - This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
@graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.
This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
This is a natural extension of #4887, and handles the following three cases:
~~~~
a line with only /s
////////////////////////////////////////////
a line with only /s followed by whitespace
////////////////////////////////////////////
a block comment with only *s between two /s
/********************************/
~~~~
r?
Apply deriving_eq to the data structures in ast.rs, and get rid of the custom definitions of eq that were everywhere. resulting ast.rs is about 400 lines shorter.
Also: add a few test cases and a bunch of comments.
Also: change ast_ty_to_ty_cache to use node ids rather than ast::ty's. I believe this was a suggestion related to my changes, and it appears to pass all tests.
Also: tiny doc fix, remove references to crate keywords.
Note that the replaced definition of equality on tokens
contains a *huge* shortcut on INTERPOLATED tokens (those
that contain ASTs), whereby any two INTERPOLATED tokens
are considered equal. This seems like a really broken
notion of equality, but it appears that the existing
test cases and the compiler don't depend on it. Niko
noticed this, BTW.
Replace long definition of Eq on tokens and binops
w
r?
It looks to me like the string_reader and tt_reader structs are
GC pointers only because they predate the modern borrow system.
This commit leaves the type names string_reader and tt_reader alone
(they still refer to GC-ed pointers), but internally the functions
now use borrowed pointers to refer to these structures. My guess
would be that it's possible to move this change outward and not
use the GCed pointers at all, but that change looks like it could be
a larger one. Actually, I'm delighted at how quick this change was.
It looks to me like the string_reader and tt_reader structs are
GC pointers only because they predate the modern borrow system.
This commit leaves the type names string_reader and tt_reader alone
(they still refer to GC-ed pointers), but internally the functions
now use borrowed pointers to refer to these structures. My guess
would be that it's possible to move this change outward and not
use the GCed pointers at all, but that change looks like it could be
a larger one. Actually, I'm delighted at how quick this change was.
- Moved ToStr implementation of unsigned integers to uint-template.rs.
- Marked the `str()` function as deprecated.
- Forwarded all conversion functions to `core::num::to_str_common()`
and `core::num::from_str_common()`.
- Fixed most places in the codebase where `to_str()` is being used.
- Added uint-template to_str and from_str overflow tests.
LinearMap is quite a bit faster, and is fully owned/sendable without
requiring copies. The older std::map also doesn't use explicit self and
relies on mutable fields.
