r? @graydon
This removes `log` from the language. Because we can't quite implement it as a syntax extension (probably need globals at the least) it simply renames the keyword to `__log` and hides it behind macros.
After this the only way to log is with `debug!`, `info!`, etc. I figure that if there is demand for `log!` we can add it back later.
I am not sure that we ever agreed on this course of action, though I *think* there is consensus that `log` shouldn't be a statement.
This is the first in a series of patches I'm working on to clean up the code related to `deriving`. This patch allows
```
#[deriving_eq]
#[deriving_iter_bytes]
#[deriving_clone]
struct Foo { bar: uint }
```
to be replaced with:
```
#[deriving(Eq, IterBytes, Clone)]
struct Foo { bar: uint }
```
It leaves the old attributes alone for the time being.
Eventually I'd like to incorporate the new closest-match-suggestion infrastructure for mistyped trait names, and also pass the sub-attributes to the deriving code, so that the following will be possible:
```
#[deriving(TotalOrd(qux, bar))]
struct Foo { bar: uint, baz: char, qux: int }
```
This says to derive an `impl` in which the objects' `qux` fields are compared first, followed by `bar`, while `baz` is ignored in the comparison. If no fields are specified explicitly, all fields will be compared in the order they're defined in the `struct`. This might also be useful for `Eq`. Coming soon.
r?
`log` can polymorphically log anything, but debug!, etc. requires a format string. With this patch you can equivalently write `debug!(foo)` or `debug!("%?", foo)`.
I'm doing this because I was trying to remove `log` (replacing it with nothing, at least temporarily), but there are a number of logging statements that just want to print an arbitrary value and don't care about the format string.
I'm not entirely convinced this is a good change, since it overloads the implementation of these macros and makes their usage slightly more nuanced.
The one thing `log` can still do is polymorphically log anything,
but debug!, etc. require a format string. With this patch
you can equivalently write `debug!(foo)` or `debug!("%?", foo)`
After the removal of the "restricted keyword" feature in 0c82c00dc4 , there's no longer any difference between parse_ident() and parse_value_ident(), and therefore no difference between parse parse_path_without_tps() and parse_value_path(). I've collapsed all of these, removing the redundant functions and eliminating the need for two higher-order arguments.
Macro invocations with path separators (e.g. foo::bar!()) now produce a sensible error message, rather than an assertion failure. Also added compile-fail test case.
Fixes#5218 ?
I've found that unused imports can often start cluttering a project after a long time, and it's very useful to keep them under control. I don't like how Go forces a compiler error by default and it can't be changed, but I certainly want to know about them so I think that a warn is a good default.
Now that the `unused_imports` lint option is a bit smarter, I think it's possible to change the default level to warn. This commit also removes all unused imports throughout the compiler and libraries (500+).
The only odd things that I ran into were that some `use` statements had to have `#[cfg(notest)]` or `#[cfg(test)]` based on where they were. The ones with `notest` were mostly in core for modules like `cmp` whereas `cfg(test)` was for tests that weren't part of a normal `mod test` module.
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.
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.
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.
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.
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.
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.
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.
- 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
and rename "class" to "struct" everywhere possible (except local
vars, I was too lazy for that) -- that is why this commit is so
big.
No review, just dead code removal and renaming.
Closes#3515
Change ast::ty_param_bound so that all ty param bounds are represented
as traits, with no special cases for Copy/Send/Owned/Const.
typeck::collect generates the special cases.
A consequence of this is that code using the #[no_core] attribute
can't use the Copy kind/trait. Probably not a big deal?
As a side effect, any user-defined traits that happen to be called
Copy, etc. in the same module override the built-in Copy trait.
r=nmatsakis
Closes#2284
Two separate changes that got intertwined (sorry):
Make to_str pure. Closes#3691
In str, change functions like push_char to take an &mut str instead of
an &str. Closes#3710
One instance remains in net_tcp due to a foreign fn. Lots of
instances remain in serialization.rs, but IIRC that is being removed.
I had to do unholy things to task-perf-word-count-generic to get it
to compile after demoding pipes. I may well have messed up its
performance, but it passes.
Everything should now call ptr::addr_of instead of
ptr::p2::addr_of. Only the pipes macro code when compiled
by stage0 will call ptr::p2::addr_of. Needs a snapshot to get
rid of that.
Currently, the new version is ptr::p2::addr_of and the old one is
ptr::addr_of. This is kind of cheesy, but I need a snapshot before I
can ditch the old version, since the pipe compiler generates calls to
addr_of.
core is converted over to use the new version, std is not.
This will help with the auto_serialize2 migration. We have to change
ident from a type alias to uint into a unique type. We need to use
a struct instead of a "enum ident = token::str_num" because structs
support constants, but newtypes do not.
Unfortunately this trips over issue (#3585), where auto-ref isn't
playing nicely with @T implementations. Most serializers don't
care, but prettyprint2 won't properly display "@" until #3585 is
fixed.
