- 23 4月, 2012 11 次提交
-
-
由 Marijn Haverbeke 提交于
Closes #2255
-
由 Marijn Haverbeke 提交于
-
由 Marijn Haverbeke 提交于
-
由 Marijn Haverbeke 提交于
-
由 Marijn Haverbeke 提交于
-
由 Marijn Haverbeke 提交于
-
由 Marijn Haverbeke 提交于
Closes #2185
-
由 Brian Anderson 提交于
Figure the rest out in the parser
-
由 Brian Anderson 提交于
Use lookahead in the parser
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
- 22 4月, 2012 5 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
- 21 4月, 2012 24 次提交
-
-
由 Tim Chevalier 提交于
In the "not all paths return" error message, typestate was printing the AST type from the fn decl, not the ty::t type. This ended in tears when the AST return type was "ty_infer". Now it looks up the function node ID's type and uses util::ppaux::ty_to_str instead. Closes #2163.
-
由 Graydon Hoare 提交于
-
由 Graydon Hoare 提交于
-
由 Graydon Hoare 提交于
-
由 Brian Anderson 提交于
ignore high_level_loop tests in std
-
由 Jeff Olson 提交于
until race issue with (most likely) refcount scheme is sorted out
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
.. leveraging std::uv, we have: timer::delayed_send - send a value over a provided channel after the timeout has passed timer::sleep - block the current task for the specified period both of these fns (and everything that goes in timer.rs) leverage the uv_timer_* API
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
.. fixes issue, in previous commit, with global loop test hanging on 32bit linux (this was because the struct was too small, so (presumably), the data member was garbled.. yippy)
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
- moved global loop tests, as well.. will add tests in uv_hl that encompass rolling your own high_level_loop via uv::hl::run_high_level_loop() - also whitespace cleanups and misc warning cleanup.. - doesn't work on 32bit linux
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
.. seeing an occasional valgrind/barf spew on some invalid read/writes.. need to investigate further.. i think its related to my poor citizen conduct, re: pointers stashed in rust_kernel..
-
由 Jeff Olson 提交于
- starting/stoping the loop based on client work is functioning, correctly - the issue appears to be that, when the process is about to exit, the signal to let weak tasks know that they need to exit isn't getting fired.
-