The `each_line` function in `ReaderUtil` acts very differently to equivalent functions in Python, Ruby, Clojure etc. E.g. given a file `t` with contents `trailing\nnew line\n` and `n` containing `no trailing\nnew line`:
Rust:
```Rust
t: ~[~"trailing", ~"new line", ~""]
n: ~[~"no trailing", ~"new line"]
```
Python:
```Python
>>> open('t').readlines()
['trailing\n', 'new line\n']
>>> open('n').readlines()
['no trailing\n', 'new line']
```
Ruby:
```Ruby
irb(main):001:0> File.readlines('t')
=> ["trailing\n", "new line\n"]
irb(main):002:0> File.readlines('n')
=> ["no trailing\n", "new line"]
```
Clojure
```Clojure
user=> (read-lines "t")
("trailing" "new line")
user=> (read-lines "n")
("no trailing" "new line")
```
The extra string that rust includes at the end is inconsistent, and means that it is impossible to distinguish between the "real" empty line a file that ends `...\n\n`, and the "fake" one after the last `\n`.
The code attached makes Rust's `each_line` act like Clojure (and PHP, i.e. not including the `\n`), as well as adjusting `str::lines` to fix the trailing empty line problem.
Also, add a convenience `read_lines` method to read all the lines in a file into a vector.
Specifically, `lines` and `each_line` will not emit a trailing empty string
when given "...\n". Also, add `read_lines`, which just collects all of
`each_line` into a vector, and `split_*_no_trailing` which will is the
generalised version of `lines`.
This makes the `trim` and `substr` functions return a slice instead of an `~str`, and removes the unnecessary `Trimmable` trait (`StrSlice` already contains the same functionality).
Also moves the `ToStr` implementations for the three str types into the str module in anticipation of further untangling.
The old string benchmarks weren't very useful because the strings weren't long enough, so I just threw those out for now. I left out benchmarks of `oldmap` because it's clear that it's 30-40% slower and it doesn't implement the `Map` trait.
This also cleanly divides up `insert`, `search` and `remove`.
Adds an assert_eq! macro that asserts that its two arguments are equal. Error messages can therefore be somewhat more informative than a simple assert, because the error message includes "expected" and "given" values.
A slice now always refers to something that returns an borrowed pointer, views don't exist anymore. If you want to have an explictit copy of a slice, use `to_owned()`
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
r?
I want to use this function as a method. There's probably a better way to design this but the existing `ToBytes` trait is not what I am looking for (it has a parameter to indicate the byte order).
adjusting a few foreign functions that were declared with by-ref
mode. This also allows us to remove by-val mode in the near future.
With copy mode, though, we have to be careful because Rust will implicitly pass
somethings by pointer but this may not be the C ABI rules. For example, rust
will pass a struct Foo as a Foo*. So I added some code into the adapters to
fix this (though the C ABI rules may put the pointer back, oh well).
This patch also includes a lint mode for the use of by-ref mode
in foreign functions as the semantics of this have changed.
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.
The correct opendir/readdir to use appear to be the 64-bit versions called
opendir$INODE64, etc. but for some reason I can't get them to link properly
on i686. Putting them in librustrt and making gcc figure it out works.
This mystery will have to wait for another day.
This will allow you to use the `+` operator to add together any two
Options, assuming that the contents of each Option likewise implement
`+`. So Some(4) + Some(1) == Some(5), and adding with None leaves the
other value unchanged.
This might be monoidic? I don't know what that word means!
This will allow you to use the + operator to add together any two
Options, assuming that the contents of each Option likewise implement
+. So Some(4) + Some(1) == Some(5), and adding with None leaves the
other value unchanged.
This might be monoidic? I don't know what that word means!
Two changes:
- The first fixes an inconsistency in coherence whereby extension methods were added to the inherent methods table, but only in cross-crate scenarios. This causes some minor fallout in tests and so forth. In one case (comm) I added inherent and trait methods so as to avoid the need to import traits like `GenericPort` just to use a port.
- The second makes objects not implement the associated trait, as discussed in #5087.
r? @pcwalton
When parsing bytes from a wire, there is a need to parse floating-point bytes to float values ([u8*4] to f32, [u8*8] to f64). This can be done via cast::transmute, but there is no way to do it safely.
It's quite common, so I think I't better to support it in core library.
7.3x speedup in string map search speed on a microbenchmark of pure hashmap
searching against a constant string, due to the lack of allocations.
I ran into a few snags.
1. The way the coherence check is set up, I can't implement `Equiv<@str>` and
`Equiv<~str>` for `&str` simultaneously.
2. I wanted to implement `Equiv<T>` for all `T:Eq` (i.e. every type can be
compared to itself if it implements `Eq`), but the coherence check didn't
like that either.
3. I couldn't add this to the `Map` trait because `LinearMap` needs special
handling for its `Q` type parameter: it must not only implement `Equiv<T>`
but also `Hash` and `Eq`.
4. `find_equiv(&&"foo")` doesn't parse, because of the double ampersand. It has
to be written `find_equiv(& &"foo")`. We can probably just fix this.
Nevertheless, this is a huge win; it should address a major source of
performance problems, including the one here:
http://maniagnosis.crsr.net/2013/02/creating-letterpress-cheating-program.html
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.
This is an implementation of a map and set for integer keys. It's an ordered container (by byte order, which is sorted order for integers and byte strings when done in the right direction) with O(1) worst-case lookup, removal and insertion. There's no rebalancing or rehashing so it's actually O(1) without amortizing any costs.
The fanout can be adjusted in multiples of 2 from 2-ary through 256-ary, but it's hardcoded at 16-ary because there isn't a way to expose that in the type system yet. To keep things simple, it also only allows `uint` keys, but later I'll expand it to all the built-in integer types and byte arrays.
There's quite a bit of room for performance improvement, along with the boost that will come with dropping the headers on `Owned` `~` and getting rid of the overhead from the stack switches to the allocator. It currently does suffix compression for a single node and then splits into two n-ary trie nodes, which could be replaced with an array for at least 4-8 suffixes before splitting it. There's also the option of doing path compression, which may be a good or a bad idea and depends a lot on the data stored.
I want to share the test suite with the other maps so that's why I haven't duplicated all of the existing integer key tests in this file. I'll send in another pull request to deal with that.
Current benchmark numbers against the other map types:
TreeMap:
Sequential integers:
insert: 0.798295
search: 0.188931
remove: 0.435923
Random integers:
insert: 1.557661
search: 0.758325
remove: 1.720527
LinearMap:
Sequential integers:
insert: 0.272338
search: 0.141179
remove: 0.190273
Random integers:
insert: 0.293588
search: 0.162677
remove: 0.206142
TrieMap:
Sequential integers:
insert: 0.0901
search: 0.012223
remove: 0.084139
Random integers:
insert: 0.392719
search: 0.261632
remove: 0.470401
@graydon is using an earlier version of this for the garbage collection implementation, so that's why I added this to libcore. I left out the `next` and `prev` methods *for now* because I just wanted the essentials first.
This allows `TreeMap`/`TreeSet` to fully express their requirements and reduces the comparisons from ~1.5 per level to 1 which really helps for string keys.
I also added `ReverseIter` to the prelude exports because I forgot when I originally added it.
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
}
}
```
r?
This fixes the current [random failures](http://buildbot.rust-lang.org/builders/auto-linux/builds/291/steps/test/logs/stdio) on the bots and closes#4436 by removing `unwrap_shared_mutable_state` and the code that depends on it. The result is that ARC-like things will not be unwrappable. This feature is complex and is not used outside of test cases.
Note that there is not consensus to remove it.
(second commit)
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.
See issue #4869. I'm not quite sure what constitutes "consensus from the core team" (cf. discussion in the issue), but this at least demonstrates that the proposed change is pretty straightforward.
After this change, there are no new test failures. I've un-ignored the `to_str` vectors test; it's not at all obvious to me why it'd be problematic, and it passes on my Linux machine.
r?
#3406
Pretty straightforward. I'm using opaque pointers instead trying to get trans and core to agree on the types of the main function and crate map. One oddity is that this required changing the order of the `-lrustrt` argument to the linker in order to resolve `upcall_new_stack`. Linkers are mysterious.
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.
This pull request moves the logic from os::make_absolute() into the path module and fixes path joining for Windows. It does this by adding an ``unsafe_join()`` function that implements the operating system's path joining semantics.
Additionally it also adds an ``is_restricted()`` method to the trait which will return true if the path points to a windows device file.
These couldn't be overridden and so ended up being quite restrictive. This has
the side effect of changing the stringification of ~vecs, but nothing in
relied on this. Closes#4869.
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.
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.
For Issue #4709:
**c531506 rt: rand.rs expects `rust_next()` to return `uint32_t`, not `size_t`**
rand.rs expects `rustrt::rand_next()` to return `u32`, but the `rand_next()` C function returns `size_t`: ca71c6ec5b/src/libcore/rand.rs (L34)
**f4320b6 move isaac RNG utility functions to new rust_rng.cpp file**
**665e900 encapsulate isaac RNG in `rust_rng` struct**
Move isaac's `randctx` into a `rust_rng` struct to make names similar to `rand::Rng` function names and prepare for auto-reseeding in the next commit.
**9a78dc9 reseed `rust_rng` after generating 32KB**
Precedents from other languages:
* Haskell's `GenAutoReseed` generator reseeds itself after generating 32KB: http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/Crypto-Random-DRBG.html#t:GenAutoReseed
* Go's RNG reseeds itself after generating 1MB: https://code.google.com/p/go/source/browse/src/pkg/crypto/rand/rand_unix.go?name=go1.0.3#94
**9a76d71 don't deplete RNG entropy when there is only one runnable task**
`rust_sched_loop::schedule_task()` unnecessarily calls `isaac_rand()` for the common case when there is only 1 runnable task, thus depleting RNG entropy and incurring unnecessary overhead.
There are no more poor hash functions left in the codebase, and it makes
sense to rely on there being a good hash function thanks to the
inclusion of SipHash and the ease of using it with custom types.
Closes#3041
I removed the unused wrappers methods named `calloc` because they relied on the malloc wrapper having a `bool zero = true` default parameter (which resulted in some accidental zeroing). Perhaps wrapping the actual calloc function would be useful, but I don't know of an existing use case that could use it so I just removed these.
This gives an ~1% performance improvement for TreeMap, which does a lot of small allocations. Vectors use `realloc` which didn't zero before these changes so there's no measurable change in performance.
This patch finishes removing inner vector mutability from the vast majority of the compiler. Exceptions:
* core::dvec: ideally this entire type will be able to be replaced by `~[]`, but Niko asked me to hold off on removing Dvecs until he makes some fixes to borrowed pointers.
* liveness: liveness.rs is an impenetrable neutron star of deprecated semantics.
* compile-fail: I'm not sure if a lot of these tests are testing inner mutability or mutability in general. I figure that RIMOVing this folder should wait until this syntax is removed from the parser.
I also took this chance to remove many of the inner-mutability-related functions from core::vec, or as many uses of those functions as possible where still necessary. consume_mut and append_mut have been axed. cast_to_mut and cast_from_mut are still needed in a few places.
...ear
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
r? @catamorphism
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
5283a8b reworks the TreeMap lazy iterator to use `&mut` again, which closes#4763. It gets the performance of the set methods back in the same ballpark that it was pre-INHTWAMA which is nice. These can be turned back into methods eventually.
e5b6334 removes the transitional smallintmap attributes which closes#4737.
Also adds Rng::gen() for generically generating any type that implements the Rand trait. There's no way to generate things with a length (for e.g. strings or vectors), because I can't think of an elegant way to do that. Maybe have a RandLen trait that inherits Rand?
This can be used for a quickcheck mechanism I'm working on.
Calling it on a special value now causes a failure, however `to_str_radix_special()` is provided which can be
used if those values are expected, and which returns a tupel to allow differentating them.
Also fixed all conflicting calls of the old functions in the rest of the codebase.
The set of string conversion functions for each float type now consists of those items:
- to_str(), converts to number in base 10
- to_str_hex(), converts to number in base 16
- to_str_radix(), converts to number in given radix
- to_str_exact(), converts to number in base 10 with a exact number of trailing digits
- to_str_digits(), converts to number in base 10 with a maximum number of trailing digits
- implementations for to_str::ToStr and num::ToStrRadix
- from_str(), parses a string as number in base 10 including decimal exponent and special values
- from_str_hex(), parses a string as a number in base 16 including binary exponent and special values
- from_str_radix(), parses a string as a number in a given base excluding any exponent and special values
- implementations for from_str::FromStr and num::FromStrRadix
- 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.
- Moved ToStr implementation of integers to int-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 int-template to_str and from_str overflow tests.
They unify the different implementations that exists in int-template.rs, uint-template.rs and float.rs into one pair of functions, which are also in principle usable for anything that implements the necessary numeric traits. Their usage is somewhat complex due to the large amount of arguments each one takes, but as they're not meant to be used directly that shouldn't be a problem.
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.
