This should close#9468.
I removed the test stating that nested comments should not be implemented.
I had a little chicken-and-egg problem because a comment of the std contains "/*", and adding support for nested comment creates a backward incompatibility in that case, so I had to use a dirty hack to get stage1 and stage2 to compile. This part should be revert when this commit lands in a snapshot.
This is my first non-typo contribution, so I'm open to any comment.
This commit re-introduces the functionality of __morestack in a way that it was
not originally anticipated. Rust does not currently have segmented stacks,
rather just large stack segments. We do not detect when these stack segments are
overrun currently, but this commit leverages __morestack in order to check this.
This commit purges a lot of the old __morestack and stack limit C++
functionality, migrating the necessary chunks to rust. The stack limit is now
entirely maintained in rust, and the "main logic bits" of __morestack are now
also implemented in rust as well.
I put my best effort into validating that this currently builds and runs successfully on osx and linux 32/64 bit, but I was unable to get this working on windows. We never did have unwinding through __morestack frames, and although I tried poking at it for a bit, I was unable to understand why we don't get unwinding right now.
A focus of this commit is to implement as much of the logic in rust as possible. This involved some liberal usage of `no_split_stack` in various locations, along with some use of the `asm!` macro (scary). I modified a bit of C++ to stop calling `record_sp_limit` because this is no longer defined in C++, rather in rust.
Another consequence of this commit is that `thread_local_storage::{get, set}` must both be flagged with `#[rust_stack]`. I've briefly looked at the implementations on osx/linux/windows to ensure that they're pretty small stacks, and I'm pretty sure that they're definitely less than 20K stacks, so we probably don't have a lot to worry about.
Other things worthy of note:
* The default stack size is now 4MB instead of 2MB. This is so that when we request 2MB to call a C function you don't immediately overflow because you have consumed any stack at all.
* `asm!` is actually pretty cool, maybe we could actually define context switching with it?
* I wanted to add links to the internet about all this jazz of storing information in TLS, but I was only able to find a link for the windows implementation. Otherwise my suggestion is just "disassemble on that arch and see what happens"
* I put my best effort forward on arm/mips to tweak __morestack correctly, we have no ability to test this so an extra set of eyes would be useful on these spots.
* This is all really tricky stuff, so I tried to put as many comments as I thought were necessary, but if anything is still unclear (or I completely forgot to take something into account), I'm willing to write more!
This commit resumes management of the stack boundaries and limits when switching
between tasks. This additionally leverages the __morestack function to run code
on "stack overflow". The current behavior is to abort the process, but this is
probably not the best behavior in the long term (for deails, see the comment I
wrote up in the stack exhaustion routine).
d4a32386f3b6 broke these since slice_to() and slice_from() must get character
boundaries, and arbitrary needle lengths don't necessarily map to character
boundaries of the haystack.
This also adds new tests that would have caught this bug.
d4a32386f3b6 broke these since slice_to() and slice_from() must get character
boundaries, and arbitrary needle lengths don't necessarily map to character
boundaries of the haystack.
This also adds new tests that would have caught this bug.
Hello,
First time rust contributor here, please let me know if I need to sort out the contribution agreement for this.
I picked issue #9755 to dip my toe in the water, this pull request isn't quite complete though as I have not updated the documentation. The reason for this is that I haven't tracked down why this feature is gated so I don't feel I can write a justification of the same quality as the other features have been documented.
If someone would like to explain or point me at a mail thread I am happy to update with this change.
Hopefully I have understood the process of converting the old flag into a directive correctly.
Also just to call out what I am sure if a known quirk when adding feature directives, you can't build this code unless you have a snapshot of the compiler which knows about the feature directive. Chicken and the egg. I split the change into two commits, the first should be able to build a snapshot that can compile the second.
std::iter: Introduce .by_ref() adaptor
Creates a wrapper around a mutable reference to the iterator.
This is useful to allow applying iterator adaptors while still
retaining ownership of the original iterator value.
Example::
let mut xs = range(0, 10);
// sum the first five values
let partial_sum = xs.by_ref().take(5).fold(0, |a, b| a + b);
assert!(partial_sum == 10);
// xs.next() is now `5`
assert!(xs.next() == Some(5));
---
This adaptor requires the user to have good understanding of
iterators or what a particular adaptor does. There could be some
pitfalls here with the iterator protocol, it's mostly the same issues
as other places regarding what happens after the iterator
returns None for the first time.
There could also be other ways to achieve the same thing, for
example Implementing iterator on `&mut T` itself:
`impl <T: Iterator<..>> Iterator for &mut T` but that would only
lead to confusion I think.
The goal here is to avoid requiring a division or multiplication to compare against the length. The bounds check previously used an incorrect micro-optimization to replace the division by a multiplication, but now neither is necessary *for slices*. Unique/managed vectors will have to do a division to get the length until they are reworked/replaced.
