Implement method .cycle() that repeats an iterator endlessly
Implement Clone for simple iterators (without closures), including VecIterator.
> The theory is simple, the immutable iterators simply hold state
> variables (indicies or pointers) into frozen containers. We can freely
> clone these iterators, just like we can clone borrowed pointers.
The theory is simple, the immutable iterators simply hold state
variables (indicies or pointers) into frozen containers. We can freely
clone these iterators, just like we can clone borrowed pointers.
VecIterator needs a manual impl to handle the lifetime struct member.
.chain_mut_ref() is the mutable alternative to .chain_ref().
A use case example for this method is extraction of an optional value
from an Option<Container> value.
Some notes about the commits.
Exit code propagation commits:
* ```Reimplement unwrap()``` has the same old code from ```arc::unwrap``` ported to use modern atomic types and finally (it's considerably nicer this way)
* ```Add try_unwrap()``` has some new slightly-tricky (but pretty simple) concurrency primitive code
* ```Add KillHandle``` and ```Add kill::Death``` are the bulk of the logic.
Task killing commits:
* ```Implement KillHandle::kill() and friends```, ```Do a task-killed check```, and ```Add BlockedTask``` implement the killing logic;
* ```Change the HOF context switchers``` turns said logic on
Linked failure commits:
* ```Replace *rust_task ptrs``` adapts the taskgroup code to work for both runtimes
* ```Enable taskgroup code``` does what it says on the tin.
r? @brson
r? @brson `rustpkg build`, if executed in a package source directory inside
a workspace, will now build that package. By "inside a workspace"
I mean that the parent directory has to be called `src`, and rustpkg
will create a `build` directory in .. if there isn't already one.
Same goes for `rustpkg install` and `rustpkg clean`.
For the time being, `rustpkg build` (etc.) will still error out if
you run it inside a directory whose parent isn't called `src`.
I'm not sure whether or not it's desirable to have it do something
in a non-workspace directory.
`rustpkg build`, if executed in a package source directory inside
a workspace, will now build that package. By "inside a workspace"
I mean that the parent directory has to be called `src`, and rustpkg
will create a `build` directory in .. if there isn't already one.
Same goes for `rustpkg install` and `rustpkg clean`.
For the time being, `rustpkg build` (etc.) will still error out if
you run it inside a directory whose parent isn't called `src`.
I'm not sure whether or not it's desirable to have it do something
in a non-workspace directory.
Updated all users of HashMap, HashSet ::consume() to use
.consume_iter().
Since .consume_iter() takes the map or set by value, it needs awkward
extra code to in librusti's use of @mut HashMap, where the map value can
not be directly moved out.
Addresses issue #7719
Updated all users of HashMap, HashSet old .consume() to use .consume()
with a for loop.
Since .consume() takes the map or set by value, it needs awkward
extra code to in librusti's use of @mut HashMap, where the map value can
not be directly moved out.
Simulates borrow checks for '@mut' boxes, or at least it's the same idea. This allows you to store owned values, but mutate them while they're owned by TLS.
This should remove the necessity for a `pop`/`set` pattern to mutate data structures in TLS.
Changes int/uint range_rev to iterate over range `(hi,lo]` instead of `[hi,lo)`.
Fix#5270.
Also:
* Adds unit tests for int/uint range functions
* Updates the uses of `range_rev` to account for the new semantics. (Note that pretty much all of the updates there were strict improvements to the code in question; yay!)
* Exposes new function, `range_step_inclusive`, which does the range `[hi,lo]`, (at least when `hi-lo` is a multiple of the `step` parameter).
* Special-cases when `|step| == 1` removing unnecessary bounds-check. (I did not check whether LLVM was already performing this optimization; I figure it would be a net win to not leave that analysis to the compiler. If reviewer objects, I can easily remove that from the refactored code.)
(This pull request is a rebased version of PR #7524, which went stale due to recent unrelated changes to num libraries.)
Note that the headers are still on `~[T]` when `T` is managed. This is continued from #7605, which removed all the code relying on the headers and removed them from `~T` for non-managed `T`.
Implement the difference, union, etc iterators with the help of a custom
iterator combinator with explicit closure environment. Reported issue #7814
to be able to use the std::iterator filter combinator.
If the TLS key is 0-sized, then the linux linker is apparently smart enough to
put everything at the same pointer. OSX on the other hand, will reserve some
space for all of them. To get around this, the TLS key now actuall consumes
space to ensure that it gets a unique pointer
Fixes most of #4989. I didn't add Persistent{Set,Map} since the only
persistent data structure is fun_treemap and its functionality is
currently too limited to build a trait out of.
Rust will allow to supply default methods for all four methods, but we
don't have any nice error reporting for the case where at least one
method must be implemented, but it's arbitrary which.
So in this case, we require `lt`, but allow implementing the others if needed.
It will be simpler to implement only one method for Ord, while we also
allow implementing all four Ord methods for semantics or performance
reasons.
We only supply three default methods (and not four), because don't have
any nice error reporting for the case where at least one method must be
implemented, but it's arbitrary which.
Moves multibyte code to it's own function to make char_range_at
easier to inline, and faster for single and multibyte chars.
Benchmarked reading example.json 100 times, 1.18s before, 1.08s
after.
Also, optimize str::is_utf8 for the single and multibyte case
Before:
is_utf8_ascii: 272.355162 ms
is_utf8_multibyte: 167.337334 ms
After:
is_utf8_ascii: 218.088049 ms
is_utf8_multibyte: 134.836722 ms
cc #6004 and #3273
This is a rewrite of TLS to get towards not requiring `@` when using task local storage. Most of the rewrite is straightforward, although there are two caveats:
1. Changing `local_set` to not require `@` is blocked on #7673
2. The code in `local_pop` is some of the most unsafe code I've written. A second set of eyes should definitely scrutinize it...
The public-facing interface currently hasn't changed, although it will have to change because `local_data::get` cannot return `Option<T>`, nor can it return `Option<&T>` (the lifetime isn't known). This will have to be changed to be given a closure which yield `&T` (or as an Option). I didn't do this part of the api rewrite in this pull request as I figured that it could wait until when `@` is fully removed.
This also doesn't deal with the issue of using something other than functions as keys, but I'm looking into using static slices (as mentioned in the issues).
00da76d r=cmr
6e75f2d r=cmr
This implements the trait for vector iterators, replacing the reverse
iterator types. The methods will stay, for implementing the future
reverse Iterable traits and convenience.
This can also be trivially implemented for circular buffers and other
variants of arrays like strings.
The `DoubleEndedIterator` trait will allow for implementing algorithms
like in-place reverse on generic mutable iterators.
The naming (`Range` vs. `Iterator`, `Bidirectional` vs. `DoubleEnded`)
can be bikeshedded in the future.
Moves multibyte code to it's own function to make char_range_at
easier to inline, and faster for single and multibyte chars.
Benchmarked reading example.json 100 times, 1.18s before, 1.08s
after.
All of the examples were still using `core::` instead of `std::` and needed a `use std::rand;` at the top to compile
Most of the examples had
`rng = rand::rng();`
instead of
`let mut rng = rand::rng();`
This implements the trait for vector iterators, replacing the reverse
iterator types. The methods will stay, for implementing the future
reverse Iterable traits and convenience.
This can also be trivially implemented for circular buffers and other
variants of arrays like strings and `SmallIntMap`/`SmallIntSet`.
The `DoubleEndedIterator` trait will allow for implementing algorithms
like in-place reverse on generic mutable iterators.
The naming (`Range` vs. `Iterator`, `Bidirectional` vs. `DoubleEnded`)
can be bikeshedded in the future.
The examples were still using `core::` instead of `std::`
All of the examples needed a `use std::rand;` at the top to compile
Most of the examples had
`rng = rand::rng();`
instead of
`let mut rng = rand::rng();`
r? @graydon, @nikomatsakis, @pcwalton, or @catamorphism
Sorry this is so huge, but it's been accumulating for about a month. There's lots of stuff here, mostly oriented toward enabling multithreaded scheduling and improving compatibility between the old and new runtimes. Adds task pinning so that we can create the 'platform thread' in servo.
[Here](e1555f9b56/src/libstd/rt/mod.rs (L201)) is the current runtime setup code.
About half of this has already been reviewed.
