- 16 3月, 2015 7 次提交
-
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
[breaking-change] Closes #23266
-
由 Nick Cameron 提交于
-
由 bors 提交于
This commit starts to organize the `std::os::$platform` modules and in the process stabilizes some of the functionality contained within. The organization of these modules will reflect the organization of the standard library itself with extension traits for primitives in the same corresponding module. The OS-specific modules will grow more functionality over time including concrete types that are not extending functionality of other structures, and these will either go into the closest module in `std::os::$platform` or they will grow a new module in the hierarchy. The following items are now stable: * `os::{unix, windows}` * `unix::ffi` * `unix::ffi::OsStrExt` * `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}` * `unix::ffi::OsString` * `unix::ffi::OsStringExt::{from_vec, into_vec}` * `unix::process` * `unix::process::CommandExt` * `unix::process::CommandExt::{uid, gid}` * `unix::process::ExitStatusExt` * `unix::process::ExitStatusExt::signal` * `unix::prelude` * `windows::ffi` * `windows::ffi::OsStringExt` * `windows::ffi::OsStringExt::from_wide` * `windows::ffi::OsStrExt` * `windows::ffi::OsStrExt::encode_wide` * `windows::prelude` The following items remain unstable: * `unix::io` * `unix::io::{Fd, AsRawFd}` * `unix::fs::{PermissionsExt, OpenOptionsExt}` * `windows::io` * `windows::io::{Handle, AsRawHandle}` * `windows::io::{Socket, AsRawSocket}` * `windows::fs` * `windows::fs::OpenOptionsExt` Due to the reorgnization of the platform extension modules, this commit is a breaking change. Most imports can be fixed by adding the relevant libstd module in the `use` path (such as `ffi` or `fs`). [breaking-change]
-
由 Alex Crichton 提交于
This commit starts to organize the `std::os::$platform` modules and in the process stabilizes some of the functionality contained within. The organization of these modules will reflect the organization of the standard library itself with extension traits for primitives in the same corresponding module. The OS-specific modules will grow more functionality over time including concrete types that are not extending functionality of other structures, and these will either go into the closest module in `std::os::$platform` or they will grow a new module in the hierarchy. The following items are now stable: * `os::{unix, windows}` * `unix::ffi` * `unix::ffi::OsStrExt` * `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}` * `unix::ffi::OsString` * `unix::ffi::OsStringExt::{from_vec, into_vec}` * `unix::process` * `unix::process::CommandExt` * `unix::process::CommandExt::{uid, gid}` * `unix::process::ExitStatusExt` * `unix::process::ExitStatusExt::signal` * `unix::prelude` * `windows::ffi` * `windows::ffi::OsStringExt` * `windows::ffi::OsStringExt::from_wide` * `windows::ffi::OsStrExt` * `windows::ffi::OsStrExt::encode_wide` * `windows::prelude` The following items remain unstable: * `unix::io` * `unix::io::{Fd, AsRawFd}` * `unix::fs::{PermissionsExt, OpenOptionsExt}` * `windows::io` * `windows::io::{Handle, AsRawHandle}` * `windows::io::{Socket, AsRawSocket}` * `windows::fs` * `windows::fs::OpenOptionsExt` Due to the reorgnization of the platform extension modules, this commit is a breaking change. Most imports can be fixed by adding the relevant libstd module in the `use` path (such as `ffi` or `fs`). [breaking-change]
-
由 bors 提交于
- Successful merges: #23375, #23379, #23382, #23384 - Failed merges:
-
- 15 3月, 2015 29 次提交
-
-
由 bors 提交于
r? @alexcrichton cc @vhbit
-
由 Manish Goregaokar 提交于
This changed `an String` to `a String`. Very minor change! The usage of `an String` was introduced in https://github.com/rust-lang/rust/commit/a828e7948069f310dc5b33be8edb65e5e8e0cf9a#diff-b596503c7c33ce457b6d047e351ac12bR423, which changed `an OsString` to `an String`.
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
`std::io` does not currently expose the `stdin_raw`, `stdout_raw`, or `stderr_raw` functions. According to the current plans for stdio (see rust-lang/rfcs#517), raw access will likely be provided using the platform-specific `std::os::{unix,windows}` modules. At the moment we don't expose any way to do this. As such, delete all mention of the `*_raw` functions from the `stdin`/`stdout`/`stderr` function documentation. While we're at it, remove a few `pub`s from items that aren't exposed. This is done just to lessen the confusion experienced by anyone who looks at the source in an attempt to find the `*_raw` functions.
-
由 Manish Goregaokar 提交于
Now that `old_io` is deprecated and `std::io` is stable, we should stop recommending the use of `old_io` in the module documentation.
-
由 bors 提交于
It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or `AsOsStr` instead of `AsPath`. Most of these functions do not need to take ownership of their argument, but for libraries in general it's much more ergonomic to not deal with `?Sized` at all and simply require an argument `P` instead of `&P`. This change is aimed at removing unsightly `?Sized` bounds while retaining the same level of usability as before. All affected functions now take ownership of their arguments instead of taking them by reference, but due to the forwarding implementations of `AsOsStr` and `AsPath` all code should continue to work as it did before. This is strictly speaking a breaking change due to the signatures of these functions changing, but normal idiomatic usage of these APIs should not break in practice. [breaking-change]
-
由 Tamir Duberstein 提交于
`sys/ttycom.h` in both: `#define TIOCGWINSZ _IOR('t', 104, struct winsize) /* get window size */`
-
由 Tamir Duberstein 提交于
-
由 Dabo Ross 提交于
Super minor change! The `an String` was introduced in https://github.com/rust-lang/rust/commit/a828e7948069f310dc5b33be8edb65e5e8e0cf9a#diff-b596503c7c33ce457b6d047e351ac12bR423, which changed `an OsString` to `an String`.
-
由 Alex Crichton 提交于
It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or `AsOsStr` instead of `AsPath`. Most of these functions do not need to take ownership of their argument, but for libraries in general it's much more ergonomic to not deal with `?Sized` at all and simply require an argument `P` instead of `&P`. This change is aimed at removing unsightly `?Sized` bounds while retaining the same level of usability as before. All affected functions now take ownership of their arguments instead of taking them by reference, but due to the forwarding implementations of `AsOsStr` and `AsPath` all code should continue to work as it did before. This is strictly speaking a breaking change due to the signatures of these functions changing, but normal idiomatic usage of these APIs should not break in practice. [breaking-change]
-
由 FuGangqiang 提交于
-
由 bors 提交于
r? @Manishearth
-
由 Manish Goregaokar 提交于
"body": null,
-
由 Manish Goregaokar 提交于
It was using tabs.
-
由 Manish Goregaokar 提交于
[expr; 0] currently exhibits inconsistent behaviour and [expr; n] with n > 1 triggers an LLVM assertion in case that \"expr\" diverges.
-
由 Manish Goregaokar 提交于
There was a minor typo in the book's concurrency section (\"recieve\" instead of \"receive\").
-
由 Manish Goregaokar 提交于
LLVM older that 3.6 has a bug that cause assertions when compiling certain constructs. For 3.5 there's still a chance that the bug might get fixed in 3.5.2, so let's keep allowing to compile with it for it for now.
-
由 Manish Goregaokar 提交于
This change closes #23303 by rejecting an empty search path.
-
由 Manish Goregaokar 提交于
non_camel_case_types lint suggests `ONETWOTHREE` for non-camel type `ONE_TWO_THREE`, which doesn't look good. This patch fixes it.
-
由 Manish Goregaokar 提交于
Previously it would fail on a trivial case like /// Summary line /// <trailing space> /// Regular content Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line extractor interprets both lines as the same paragraph and includes both into the short summary resulting in ![screenshot from 2015-03-13 22 47 08](https://cloud.githubusercontent.com/assets/679122/6648596/7ef792b2-c9e4-11e4-9c19-704c288ec4de.png)
-
由 bors 提交于
Previously it would fail on a trivial case like /// Summary line /// <trailing space> /// Regular content Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line extractor interprets both lines as the same paragraph and includes both into the short summary resulting in ![screenshot from 2015-03-13 22 47 08](https://cloud.githubusercontent.com/assets/679122/6648596/7ef792b2-c9e4-11e4-9c19-704c288ec4de.png)
-
由 Kevin Ballard 提交于
std::io does not currently expose the stdin_raw, stdout_raw, or stderr_raw functions. According to the current plans for stdio (see RFC #517), raw access will likely be provided using the platform-specific std::os::{unix,windows} modules. At the moment we don't expose any way to do this. As such, delete all mention of the _raw functions from the stdin/stdout/stderr function documentation. While we're at it, remove a few `pub`s from items that aren't exposed. This is done just to lessen the confusion experienced by anyone who looks at the source in an attempt to find the _raw functions.
-
由 bors 提交于
The arity of `ref x` is always 1, so it needs to be dereferenced before being compared with some other type whose arity is not 1. Fixes #23009.
-
由 Kevin Ballard 提交于
Now that `old_io` is deprecated and `std::io` is stable, we should stop recommending the use of `old_io` in the module documentation.
-
由 bors 提交于
This adds search by type (for functions/methods) support to Rustdoc. Target issue is at https://github.com/rust-lang/rfcs/issues/658. I've described my approach here: https://github.com/rust-lang/rfcs/issues/658#issuecomment-76484200. I'll copy the text in here as well: --- Hi, it took me longer than I wished, but I have implemented this in a not-too-complex way that I think can be extended to support more complex features (like the ones mentioned [here](https://github.com/rust-lang/rust/issues/12866#issuecomment-66945317)). The idea is to generate a JSON representation of the types of methods/functions in the existing index, and then make the JS understand when it should look by type (and not by name). I tried to come up with a JSON representation that can be extended to support generics, bounds, ref/mut annotations and so on. Here are a few samples: Function: ```rust fn to_uppercase(c: char) -> char ``` ```json { "inputs": [ {"name": "char"} ], "output": { "name": "char", } } ``` Method (implemented or defined in trait): ```rust // in struct Vec // self is considered an argument as well fn capacity(&self) -> usize ``` ```json { "inputs": [ {"name": "vec"} ], "output": { "name": "usize" } } ``` This simple format can be extended by adding more fields, like `generic: bool`, a `bounds` mapping and so on. I have a working implementation in https://github.com/rust-lang/rust/compare/master...mihneadb:rustdoc-search-by-type. You can check out a live demo [here](http://data.mihneadb.net/doc/std/index.html?search=charext%20-%3E%20char). ![screenshot from 2015-02-28 00 54 00](https://cloud.githubusercontent.com/assets/643127/6422722/7e5374ee-bee4-11e4-99a6-9aac3c9d5068.png) The feature list is not that long: - search by types (you *can* use generics as well, as long as you use the exact name - e.g. [`vec,t -> `](http://data.mihneadb.net/doc/std/index.html?search=vec%2C%20t%20-%3E)) - order of arguments does not matter - `self` is took into account as well (e.g. search for `vec -> usize`) - does not use "complex" annotations (e.g. you don't search for `&char -> char` but for `char -> char`) My goal is to get a working, minimal "base" merged so that others can build upon it. How should I proceed? Do I open a PR (badly in need of code review since this is my first non "hello world"-ish rust code)? ---
-
由 Eduardo Bautista 提交于
-
由 Eduardo Bautista 提交于
-
由 Mihnea Dobrescu-Balaur 提交于
-
由 bors 提交于
Oops, merged #21468 by accident.
-
- 14 3月, 2015 4 次提交
-
-
由 Barosl Lee 提交于
The arity of `ref x` is always 1, so it needs to be dereferenced before being compared with some other type whose arity is not 1. Fixes #23009.
-
由 Björn Steinbrink 提交于
-
由 Björn Steinbrink 提交于
In case that there is a destination for the array, like in "let x = [expr; n]", we currently don't evaluate the given expression if n is zero. That's inconsistent with all other cases, including "[expr; 0]" without a destination. Fixes #23354
-
由 Ricardo Martins 提交于
-