- 23 8月, 2013 40 次提交
-
-
由 bors 提交于
This resolves issue #908. Notable changes: - On Windows, LLVM integrated assembler emits bad stack unwind tables when segmented stacks are enabled. However, unwind info directives in the assembly output are correct, so we generate assembly first and then run it through an external assembler, just like it is already done for Android builds. - Linker is invoked via "g++" command instead of "gcc": g++ passes the appropriate magic parameters to the linker, which ensure correct registration of stack unwind tables in dynamic libraries.
-
由 Vadim Chugunov 提交于
-
由 Vadim Chugunov 提交于
-
由 bors 提交于
Attempt #2 of [this pull request](https://github.com/mozilla/rust/pull/8597) since my tired mind decided messing up my repo, then deleting and re-forking was a good idea. This is identical to the second last commit in that PR. (The one before I ruined everything.) This is an improvement to use_decl docs, which will hopefully improve understanding of how resolution works and where `extern mod` and module declarations should go to make them visible to use declarations.
-
由 Brandon Sanderson 提交于
-
由 bors 提交于
This PR includes the addition of the essential CRUD functionality exposed as a part of the `uv_fs_*` api. There's a lot more to be done, but the essential abstractions are in place and can be easily expanded. A summary: * `rt::io::file::FileStream` is fleshed out and behaves as a *non-positional* file stream (that is, it has a cursor that can be viewed/changed via `tell` and `seek` * The underlying abstraction in `RtioFileStream` exposes pairs of `read(), write()` and `pread(), pwrite()`. The latter two take explicit `offset` params and don't respect the current cursor location in a file afaik. They both use the same underlying libuv impl * Because libuv explicitly does *not* support `seek`/`tell` operations, these are impl'd in `UvFileStream` by using `lseek(2)` on the raw file descriptor. * I did my best to flesh out and adhere to the stubbing that was already present in `rt::io::file` and the tests should back that up. There may be things missing. * All of the work to test `seek`/`tell` is done in `rt::io::file`, even though the actual impl is down in `rt::uv::uvio`. * We have the ability to spin up an `~RtioFileStream` from a raw file descriptor. This would be useful for interacting with stdin and stdout via newrt. * The lowest level abstractions (in `rt::uv::file`) support fully synchronous/blocking interactions with the uv API and there is a CRUD test using it. This may also be useful for blocking printf, if desired (the default would be non-blocking and uses libuv's io threadpool) There are a few polish things I need to do still (the foremost that I know of is undefined behavior when seek'ing beyond the file's boundary). After this lands, I want to move on to mapping more of the `uv_fs_*` API (especially `uv_fs_stat`). Also a few people have mentioned interest in `uv_pipe_t` support. I'm open to suggestions.
-
由 Jeff Olson 提交于
-
由 bors 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
- change all uses of Path in fn args to &P - FileStream.read assumptions were wrong (libuv file io is non-positional) - the above will mean that we "own" Seek impl info .. should probably push it in UvFileDescriptor.. - needs more tests
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
the test "touch"es a new file
-
由 Michael Sullivan 提交于
-
由 bors 提交于
-
由 Alex Crichton 提交于
-
由 Michael Sullivan 提交于
-
由 Michael Sullivan 提交于
-
由 Michael Sullivan 提交于
-
由 bors 提交于
This commit removes the "super_*" functions from typeck::infer::combine, and adds them as default methods on the Combine trait instead, making it possible to remove a lot of boilerplate from the various impls of Combine. I've been wanting to do this for over a year. In fact, it was my original motivation for default methods! It might be possible to tighten things up even more, but this is the bulk of it.
-