My merges for #5143 missed a couple other copies. This patch corrects this, and gets stage0 to compile libsyntax with `#[deny(vecs_implicitly_copyable)]`. stage1 still fails though.
The fix is straight-forward, but there are several changes
while fixing the issue.
1) disallow `mut` keyword when making a new struct
In code base, there are following code,
```rust
struct Foo { mut a: int };
let a = Foo { mut a: 1 };
```
This is because of structural record, which is
deprecated corrently (see issue #3089) In structural
record, `mut` keyword should be allowd to control
mutability. But without structural record, we don't
need to allow `mut` keyword while constructing struct.
2) disallow structural records in parser level
This is related to 1). With structural records, there
is an ambiguity between empty block and empty struct
To solve the problem, I change parser to stop parsing
structural records. I think this is not a problem,
because structural records are not compiled already.
Misc. issues
There is an ambiguity between empty struct vs. empty match stmt.
with following code,
```rust
match x{} {}
```
Two interpretation is possible, which is listed blow
```rust
match (x{}) {} // matching with newly-constructed empty struct
(match x{}) {} // matching with empty enum(or struct) x
// and then empty block
```
It seems that there is no such code in rust code base, but
there is one test which uses empty match statement:
https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs
All other cases could be distinguished with look-ahead,
but this can't be. One possible solution is wrapping with
parentheses when matching with an uninhabited type.
```rust
enum what { }
fn match_with_empty(x: what) -> ~str {
match (x) { //use parentheses to remove the ambiguity
}
}
```
- Removed space between struct name and parentheses
- Fixed indentation of the rest of the file (missing end)
- Don't print parentheses for structs with no fields
- Added test
- Removed space between struct name and parentheses
- Fixed indentation of the rest of the file (missing end)
- Don't print parentheses for structs with no fields
- Added test
This removes all but 6 uses of `drop {}` from the entire codebase. Removing any of the remaining uses causes various non-trivial bugs; I'll start reporting them once this gets merged.
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
cc #4846
r? @graydon
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
cc #4846
r?
After this patch, macros declared in a module, function, or block can only be used inside of that module, function or block, with the exception of modules declared with the #[macro_escape] attribute; these modules allow macros to escape, and can be used as a limited macro export mechanism.
This pull request also includes miscellaneous comments, lots of new test cases, a few renamings, and a few as-yet-unused data definitions for hygiene.
Macro scope is now delimited by function, block, and module boundaries,
except for modules that are marked with #[macro_escape], which allows
macros to escape.
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.
These commits take the old bitv implementation and modernize it with an explicit self, some minor touchups, and using what I think is some more recent patterns (like `::new` instead of `Type()`).
Additionally, this adds an implementation of `container::Set` on top of a bit vector to have as a set of `uint`s. I initially tried to parameterize the type for the set to be `T: NumCast` but I was hitting build problems in stage0 which I think means that it's not in a snapshot yet, so it's just hardcoded as a set of `uint`s now. In the future perhaps it could be parameterized. I'm not sure if it would really add anything, though, so maybe it's nicer to be hardcoded anyway.
I also added some extra methods to do normal bit vector operations on the set in-place, but these aren't a part of the `Set` trait right now. I haven't benchmarked any of these operations just yet, but I imagine that there's quite a lot of room for optimization here and there.
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.
Issue #3869
review? @nikomatsakis
Convert all uses of vec::slice to vec::view Issue #3869
Rename const_view to const_slice
Renamed mut_view to mut_slice
Fix windows build error. `buf` is borrowed by the call to
`as_mut_buf()` and so we must invoke `slice()` outside of that
call.
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?
I added code to the JSON encoder to support the serialization of enums. Before this, the JSON serializer only handled Option, and encoded None as 'null'. Following this change, all enums are encoded as arrays containing the enum name followed by the encoded fields. This appears consistent with the unstated invariant that the resulting output can be mapped back to the input *if* there's a decoder around that knows the types that were in existence when the serialization occurred.
Also, added test cases.
The function that formats and prints the squigly line that hilights
errors counted tabs as spaces, which resulted in incorrect error
messages when tabs were used for indentation. This change compares
the highlight line with the previous line and inserts a tab instead
of a space whenever such a tab exists on the previous line. Note
that error messages will still highlight incorrectly when the
previous line include characters that require more than one utf8
code point, as mentioned in issue 3260.
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.
Changes:
- Refactor move mode computation
- Removes move mode arguments, unary move, capture clauses
(though they still parse for backwards compatibility)
- Simplify how moves are handled in trans
- Fix a number of illegal copies that cropped up
- Workaround for bug involving def-ids in params
(see details below)
Future work (I'll open bugs for these...):
- Improve error messages for moves that are due
to bindings
- Add support for moving owned content like a.b.c
to borrow check, test in trans (but I think it'll
"just work")
- Proper fix for def-ids in params
Def ids in params:
Move captures into a map instead of recomputing.
This is a workaround for a larger bug having to do with the def-ids associated
with ty_params, which are not always properly preserved when inlining. I am
not sure of my preferred fix for the larger bug yet. This current fix removes
the only code in trans that I know of which relies on ty_param def-ids, but
feels fragile.
"Dual impls" are impls that are both type implementations and trait
implementations. They can lead to ambiguity and so this patch removes them
from the language.
This also enforces coherence rules. Without this patch, records can implement
traits not defined in the current crate. This patch fixes this, and updates
all of rustc to adhere to the new enforcement. Most of this patch is fixing
rustc to obey the coherence rules, which involves converting a bunch of records
to structs.
Print out a clearer error message when a `for` gets
used with the wrong type of iterator. Also fix spans on `for` loop
bodies, and suppress some more derived errors.
r=brson
Closes#3651
- Make `extern fn()` assignable to any closure type, rather than
a subtype.
- Remove unused int_ty_set and float_ty_set
- Refactor variable unification and make it more DRY
- Do fn sub/lub/glb on the level of fn_sig
- Rename infer::to_str::ToStr to infer::to_str::InferStr
- Capitalize names of various types
- Correct hashing of FnMeta
- Convert various records-of-fns into structs-of-fns. This is both
eliminating use of deprecated features and more forwards compatible
with fn reform.
r=pcwalton
emit_struct and read_struct takes an additional len:uint parameter which tells
us how many fields the struct we are working on has.
This is required to implement an Encoder for the msgpack [1] serialization
format. To serialize a struct with msgpack you have to use arrays and the size
of the array has to be know before each of the elements are written out. JSON
as an example doesn't have this problem as it uses '[' and ']' delimiters for
arrays.
[1]: www.msgpack.org
