| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This will allow capturing of common things like logging messages, stdout prints
(using stdio println), and failure messages (printed to stderr). Any new prints
added to libstd should be funneled through these task handles to allow capture
as well.
Additionally, this commit redirects logging back through a `Logger` trait so the
log level can be usefully consumed by an arbitrary logger.
This commit also introduces methods to set the task-local stdout handles:
* std::io::stdio::set_stdout
* std::io::stdio::set_stderr
* std::io::logging::set_logger
These methods all return the previous logger just in case it needs to be used
for inspection.
I plan on using this infrastructure for extra::test soon, but we don't quite
have the primitives that I'd like to use for it, so it doesn't migrate
extra::test at this time.
Closes #6369
|
|
This will allow capturing of common things like logging messages, stdout prints
(using stdio println), and failure messages (printed to stderr). Any new prints
added to libstd should be funneled through these task handles to allow capture
as well.
Additionally, this commit redirects logging back through a `Logger` trait so the
log level can be usefully consumed by an arbitrary logger.
This commit also introduces methods to set the task-local stdout handles:
* std::io::stdio::set_stdout
* std::io::stdio::set_stderr
* std::io::logging::set_logger
These methods all return the previous logger just in case it needs to be used
for inspection.
I plan on using this infrastructure for extra::test soon, but we don't quite
have the primitives that I'd like to use for it, so it doesn't migrate
extra::test at this time.
Closes #6369
|
|
|
|
There was a scheduling race where a child may not increment the global task
count before the parent exits, and the parent would then think that there are no
more tasks left.
Closes #11039
|
|
There was a scheduling race where a child may not increment the global task
count before the parent exits, and the parent would then think that there are no
more tasks left.
|
|
|
|
pcwalton says this is right, and it looks right to me too.
Closes #4731
|
|
This reverts commit f1b5f59287106fc511d29c425255bd343608065c.
Using a private function of a library is a bad idea: several people (on
Linux) were meeting with linking errors because of it (different/older
versions of glibc).
|
|
This removes the feature where newtype structs can be dereferenced like pointers, and likewise where certain enums can be dereferenced (which I imagine nobody realized still existed). This ad-hoc behavior is to be replaced by a more general overloadable dereference trait in the future.
I've been nursing this patch for two months and think it's about rebased up to master.
@nikomatsakis this makes a bunch of your type checking code noticeably uglier.
|
|
|
|
If there is a lot of data in thread-local storage some implementations
of pthreads (e.g. glibc) fail if you don't request a stack large enough
-- by adjusting for the minimum size we guarantee that our stacks are
always large enough. Issue #6233.
|
|
I'm not sure if this was even intentional at this point.
|
|
If there is a lot of data in thread-local storage some implementations
of pthreads (e.g. glibc) fail if you don't request a stack large enough
-- by adjusting for the minimum size we guarantee that our stacks are
always large enough. Issue #6233.
|
|
|
|
|
|
|
|
it no longer has boxes in it
|
|
|
|
Had to change some stuff in typeck to bootstrap (getting methods in fmt off of Either), but other than that not so painful.
Closes #9157
|
|
|
|
|
|
Closes #11085
|
|
|
|
This patch for #9543 throws an `obsolete syntax` error for `extern mod foo (name="bar")` .
I was wondering if [this](https://github.com/fhahn/rust/compare/mozilla:master...fhahn:issue9543-remove-extern-mod-foo?expand=1#diff-da9d34ca1d0f6beee2838cf02e07345cR4444) is the correct place to do this?
I think the wording of the error message could probably be improved as well.
If this approach is OK, I'm going to run the whole test suite tomorrow and update the old syntax to the new one.
|
|
Commit messages are a little more descriptive.
|
|
|
|
The comments have more information as to why this is done, but the basic idea is
that finding an exported trait is actually a fairly difficult problem. The true
answer lies in whether a trait is ever referenced from another exported method,
and right now this kind of analysis doesn't exist, so the conservative answer of
"yes" is always returned to answer whether a trait is exported.
Closes #11224
Closes #11225
|
|
|
|
The old `rtio-processes` run-pass test is now moved into libstd's `io::process` module, and all process and TCP tests are now run with `iotest!` (both a native and a green version are tested).
All TCP networking on windows is provided by `ws2_32` which is apparently very similar to unix networking (hurray!).
|
|
Move the tests into libstd, use the `iotest!` macro to test both native and uv
bindings, and use the cloexec trick to figure out when the child process fails
in exec.
|
|
|
|
* vec::raw::to_ptr is gone
* Pausible => Pausable
* Removing @
* Calling the main task "<main>"
* Removing unused imports
* Removing unused mut
* Bringing some libextra tests up to date
* Allowing compiletest to work at stage0
* Fixing the bootstrap-from-c rmake tests
* assert => rtassert in a few cases
* printing to stderr instead of stdout in fail!()
|
|
Closes #11085
|
|
Note that this removes a number of run-pass tests which are exercising behavior
of the old runtime. This functionality no longer exists and is thoroughly tested
inside of libgreen and libnative. There isn't really the notion of "starting the
runtime" any more. The major notion now is "bootstrapping the initial task".
|
|
|
|
This uses quite a bit of unsafe code for speed and failure safety, and allocates `2*n` temporary storage.
[Performance](https://gist.github.com/huonw/5547f2478380288a28c2):
| n | new | priority_queue | quick3 |
|-------:|---------:|---------------:|---------:|
| 5 | 200 | 155 | 106 |
| 100 | 6490 | 8750 | 5810 |
| 10000 | 1300000 | 1790000 | 1060000 |
| 100000 | 16700000 | 23600000 | 12700000 |
| sorted | 520000 | 1380000 | 53900000 |
| trend | 1310000 | 1690000 | 1100000 |
(The times are in nanoseconds, having subtracted the set-up time (i.e. the `just_generate` bench target).)
I imagine that there is still significant room for improvement, particularly because both priority_queue and quick3 are doing a static call via `Ord` or `TotalOrd` for the comparisons, while this is using a (boxed) closure.
Also, this code does not `clone`, unlike `quick_sort3`; and is stable, unlike both of the others.
|
|
|
|
(implicitly) less_eq.
|
|
This moves the custom sorting to `.sort_by`.
|
|
We decided in the 12/10/13 weekly meeting that trailing commas should be
accepted pretty much anywhere. They are currently not allowed in struct
patterns, and this commit adds support for that.
Closes #10392
|
|
very small runs.
This uses a lot of unsafe code for speed, otherwise we would be having
to sort by sorting lists of indices and then do a pile of swaps to put
everything in the correct place.
Fixes #9819.
|
|
Now that the metadata is an owned value with a lifetime of a borrowed byte
slice, it's possible to have future optimizations where the metadata doesn't
need to be copied around (very expensive operation).
|
|
Now that the metadata is an owned value with a lifetime of a borrowed byte
slice, it's possible to have future optimizations where the metadata doesn't
need to be copied around (very expensive operation).
|
|
|
|
We decided in the 12/10/13 weekly meeting that trailing commas should be
accepted pretty much anywhere. They are currently not allowed in struct
patterns, and this commit adds support for that.
Closes #10392
|
|
Closes #11035
|
|
Closes #5806
Closes #8259
Closes #8578
Closes #8851
Closes #10412
|
|
Closes #5806
Closes #5950
Closes #7178
Closes #8259
Closes #8578
Closes #8851
Closes #9129
Closes #10412
|
|
With the old `for` gone, this behaviour is no longer conflicting with
that use of `return` in closures, and this allows shortcircuiting in a
closure.
|
