- 16 3月, 2015 1 次提交
-
-
由 Tamir Duberstein 提交于
-
- 15 3月, 2015 21 次提交
-
-
由 bors 提交于
r? @alexcrichton cc @vhbit
-
由 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 提交于
-
由 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]
-
由 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)
-
由 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.
-
由 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 16 次提交
-
-
由 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 提交于
-
由 Björn Steinbrink 提交于
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.
-
由 Simonas Kazlauskas 提交于
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 would interpret both lines as the same paragraph and include both into the short summary.
-
由 bors 提交于
at least that's what the docs say: http://doc.rust-lang.org/std/slice/fn.from_raw_parts.html A few situations got prettier. In some situations the mutability of the resulting and source pointers differed (and was cast away by transmute), the mutability matches now.
-
由 Ryan Prichard 提交于
It wasn't clear to me that early_error was correct here, but it seems to work. This code is reachable from `rustdoc`, which is problematic, because early_error panics. rustc handles the panics gracefully (without ICEing or crashing), but rustdoc does not. It's not the first such rustdoc problem, though: $ rustdoc hello.rs --extern std=bad-std error: extern location for std does not exist: bad-std hello.rs:1:1: 1:1 error: can't find crate for `std` hello.rs:1 ^ error: aborting due to 2 previous errors thread '<unnamed>' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:151 thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "rustc failed"', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:744 thread '<main>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread.rs:661
-
由 Manish Goregaokar 提交于
This reverts commit b042ffc4. Conflicts: src/librustc/middle/pat_util.rs
-
由 Manish Goregaokar 提交于
This reverts commit bce7a6f4.
-
由 York Xiang 提交于
-
由 bors 提交于
Reduce code size overhead from core::panicking::panic core::panicking::panic currently creates an Arguments structure using format_args!("{}", expr), which formats the expr str using the Display::fmt. Display::fmt pulls in Formatter::pad, which then also pulls in string-related code for truncation and padding. If core::panicking::panic instead creates an Arguments structure with a string piece, it is possible that the Display::fmt function for str can be optimized out of the program. In my testing with a 32-bit x86 bare metal program, the change tended to save between ~100 bytes and ~5500 bytes, depending on what other panic* functions the program invokes and whether the panic_fmt lang item uses the Arguments value.
-
由 Ryan Prichard 提交于
LLVM_LIBDIR_<triple> is only defined for host triples, not target triples. FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we explicitly define it as empty when --enable-llvm-static-stdcpp is not specified, but it's still undefined for cross-compiled triples.
-
由 bors 提交于
The new `std::io` module has had some time to bake now, and this commit stabilizes its functionality. There are still portions of the module which remain unstable, and below contains a summart of the actions taken. This commit also deprecates the entire contents of the `old_io` module in a blanket fashion. All APIs should now have a reasonable replacement in the new I/O modules. Stable APIs: * `std::io` (the name) * `std::io::prelude` (the name) * `Read` * `Read::read` * `Read::{read_to_end, read_to_string}` after being modified to return a `usize` for the number of bytes read. * `ReadExt` * `Write` * `Write::write` * `Write::{write_all, write_fmt}` * `WriteExt` * `BufRead` * `BufRead::{fill_buf, consume}` * `BufRead::{read_line, read_until}` after being modified to return a `usize` for the number of bytes read. * `BufReadExt` * `BufReader` * `BufReader::{new, with_capacity}` * `BufReader::{get_ref, get_mut, into_inner}` * `{Read,BufRead} for BufReader` * `BufWriter` * `BufWriter::{new, with_capacity}` * `BufWriter::{get_ref, get_mut, into_inner}` * `Write for BufWriter` * `IntoInnerError` * `IntoInnerError::{error, into_inner}` * `{Error,Display} for IntoInnerError` * `LineWriter` * `LineWriter::{new, with_capacity}` - `with_capacity` was added * `LineWriter::{get_ref, get_mut, into_inner}` - `get_mut` was added) * `Write for LineWriter` * `BufStream` * `BufStream::{new, with_capacities}` * `BufStream::{get_ref, get_mut, into_inner}` * `{BufRead,Read,Write} for BufStream` * `stdin` * `Stdin` * `Stdin::lock` * `Stdin::read_line` - added method * `StdinLock` * `Read for Stdin` * `{Read,BufRead} for StdinLock` * `stdout` * `Stdout` * `Stdout::lock` * `StdoutLock` * `Write for Stdout` * `Write for StdoutLock` * `stderr` * `Stderr` * `Stderr::lock` * `StderrLock` * `Write for Stderr` * `Write for StderrLock` * `io::Result` * `io::Error` * `io::Error::last_os_error` * `{Display, Error} for Error` Unstable APIs: (reasons can be found in the commit itself) * `Write::flush` * `Seek` * `ErrorKind` * `Error::new` * `Error::from_os_error` * `Error::kind` Deprecated APIs * `Error::description` - available via the `Error` trait * `Error::detail` - available via the `Display` implementation * `thread::Builder::{stdout, stderr}` Changes in functionality: * `old_io::stdio::set_stderr` is now a noop as the infrastructure for printing backtraces has migrated to `std::io`. [breaking-change]
-
由 bors 提交于
r? @Manishearth
-
由 Alex Crichton 提交于
-
- 13 3月, 2015 2 次提交
-
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
-