This is just a bunch of minor changes and simplifications to the structure of core::rt. It makes ownership of the ~Scheduler more strict (though it is still mutably aliased sometimes), turns the scheduler cleanup_jobs vector into just a single job, shunts the thread-local scheduler code off to its own file.
r? @nikomatsakis
This doesn't completely fix the x86 ABI for structs, but it does fix some cases. On linux, structs appear to be returned correctly now. On windows, structs are only returned by pointer when they are greater than 8 bytes. That scenario works now.
In the case where the struct is less than 8 bytes our generated code looks peculiar. When returning a pair of u16, C packs both variables into %eax to return them. Our generated code though expects to find one of the pair in %ax and the other in %dx. Similar for u8. I haven't looked into it yet.
There appears to also be struct passing problems on linux, where my `extern-pass-TwoU8s` and `extern-pass-TwoU16s` tests are failing.
This Adds a bunch of tests for passing and returning structs
of various sizes to C. It fixes the struct return rules on unix,
and on windows for structs of size > 8 bytes. Struct passing
on unix for structs under a certain size appears to still be broken.
In order to do a context switch you have to give up ownership of the scheduler,
effectively passing it to the next execution context. This could help avoid
some situations here tasks retain unsafe pointers to schedulers between context
switches, across which they may have changed threads.
There are still a number of uses of unsafe scheduler pointers.
Closes#5487, #1913, and #4568
I tracked this by adding all used unsafe blocks/functions to a set on the `tcx` passed around, and then when the lint pass comes around if an unsafe block/function isn't listed in that set, it's unused.
I also removed everything from the compiler that was unused, and up to stage2 is now compiling without any known unused unsafe blocks.
I chose `unused_unsafe` as the name of the lint attribute, but there may be a better name...
This takes care of one of the last remnants of assumptions about enum layout. A type visitor is now passed a function to read a value's discriminant, then accesses fields by being passed a byte offset for each one. The latter may not be fully general, despite the constraints imposed on representations by borrowed pointers, but works for any representations currently planned and is relatively simple.
Closes#5652.
This is a follow-up to #5761. Its purpose is to make core::libc more consistent - it currently only defines SIGKILL and SIGTERM, because they are the only values that happen to be needed by libcore.
This adds all the posix signal value constants, except for those that have different values on different architectures.
The output of the command `man 7 signal` was used to compile these signal values.
value constants, except for those that have different values
on different architectures.
The output of the command `man 7 signal` was used to
compile these signal values.
The foldl based implementation allocates lots of unneeded vectors.
iter::map_to_vec is already optimized to avoid these.
One place that benefits quite a lot from this is the metadata decoder, helping with compile times for tiny programs.
The current protocol is very comparable to Python, where `.__iter__()` returns an iterator object which implements `.__next__()` and throws `StopIteration` on completion. `Option` is much cleaner than using a exceptions as a flow control hack though. It requires that the container is frozen so there's no worry about invalidating them.
Advantages over internal iterators, which are functions that are passed closures and directly implement the iteration protocol:
* Iteration is stateful, so you can interleave iteration over arbitrary containers. That's needed to implement algorithms like zip, merge, set union, set intersection, set difference and symmetric difference. I already used this internally in the `TreeMap` and `TreeSet` implementations, but regions and traits weren't solid enough to make it generic yet.
* They provide a universal, generic interface. The same trait is used for a forward/reverse iterator, an iterator over a range, etc. Internal iterators end up resulting in a trait for each possible way you could iterate.
* They can be composed with adaptors like `ZipIterator`, which also implement the same trait themselves.
The disadvantage is that they're a pain to write without support from the compiler for compiling something like `yield` to a state machine. :)
This can coexist alongside internal iterators since both can use the current `for` protocol. It's easier to write an internal iterator, but external ones are far more powerful/useful so they should probably be provided whenever possible by the standard library.
## Current issues
#5801 is somewhat annoying since explicit type hints are required.
I just wanted to get the essentials working well, so I haven't put much thought into making the naming concise (free functions vs. static `new` methods, etc.).
Making an `Iterable` trait seems like it will have to be a long-term goal, requiring type system extensions. At least without resorting to objects which would probably be unacceptably slow.
This restores the trait that was lost in 216e85fadf465c25fe7bc4a9f06f8162ec12b552. It will eventually be broken up into a more fine-grained trait hierarchy in the future once a design can be agreed upon.
