- 09 4月, 2015 2 次提交
-
-
由 Alex Crichton 提交于
This commit removes pretty-expanded from all tests that wind up calling panic! one way or another now that its internals are unstable.
-
由 Alex Crichton 提交于
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no need for these two `begin_unwind` functions to be stable. Right now the `panic!` interface is the only one we wish to stabilize, so remove the stability markers from these functions. While this is a breaking change, it is highly unlikely to break any actual code. It is recommended to use the `panic!` macro instead if it breaks explicit calls into `std::rt`. [breaking-change] cc #24208
-
- 08 4月, 2015 16 次提交
-
-
由 bors 提交于
Closes #23909 r? @nikomatsakis (or anyone else, really)
-
由 bors 提交于
A recent change to the implementation of range iterators meant that, even when stepping by 1, the iterators *always* involved checked arithmetic. This commit reverts to the earlier behavior (while retaining the refactoring into traits). Fixes #24095 Closes #24119 cc #24014 r? @alexcrichton
-
由 bors 提交于
Addresses issue #22425. See `src/test/compile-fail/macro-incomplete-parse.rs` for a relevant test: macro-incomplete-parse.rs:15:9: 15:10 error: macro expansion ignores token `,` and any following macro-incomplete-parse.rs:15 , //~ ERROR macro expansion ignores token `,` ^ macro-incomplete-parse.rs:27:1: 27:17 note: caused by the macro expansion here; the usage of `ignored_item` is likely invalid in this context macro-incomplete-parse.rs:27 ignored_item!(); ^~~~~~~~~~~~~~~~ macro-incomplete-parse.rs:20:14: 20:15 error: macro expansion ignores token `,` and any following macro-incomplete-parse.rs:20 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,` ^ macro-incomplete-parse.rs:30:5: 30:21 note: caused by the macro expansion here; the usage of `ignored_expr` is likely invalid in this context macro-incomplete-parse.rs:30 ignored_expr!(); ^~~~~~~~~~~~~~~~ macro-incomplete-parse.rs:24:14: 24:15 error: macro expansion ignores token `,` and any following macro-incomplete-parse.rs:24 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,` ^ macro-incomplete-parse.rs:32:9: 32:23 note: caused by the macro expansion here; the usage of `ignored_pat` is likely invalid in this context macro-incomplete-parse.rs:32 ignored_pat!() => (), ^~~~~~~~~~~~~~ This does not address the case of improper expansion inside of an impl { } as seen in issue #21607. I'm not sure if the note text is ideal, but it can be refined if needed.
-
由 bors 提交于
Previously it could not be implemented for types outside `libcore/iter.rs` due to coherence issues.
-
由 Aaron Turon 提交于
A recent change to the implementation of range iterators meant that, even when stepping by 1, the iterators *always* involved checked arithmetic. This commit reverts to the earlier behavior (while retaining the refactoring into traits). Fixes #24095 cc #24014
-
由 Tobias Bucher 提交于
In addition to being nicer, this also allows you to use `sum` and `product` for iterators yielding custom types aside from the standard integers. Due to removing the `AdditiveIterator` and `MultiplicativeIterator` trait, this is a breaking change. [breaking-change]
-
由 bors 提交于
- Successful merges: #24132, #24139, #24147, #24148, #24150, #24166 - Failed merges:
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
This fix allows the gdb debuginfo tests to pass on FreeBSD when using the newer 7.8 package.
-
由 Manish Goregaokar 提交于
People use programming language *implementations* like Ruby MRI, CPython, and SpiderMonkey for executing programs.
-
由 Manish Goregaokar 提交于
Closes #22560
-
由 Manish Goregaokar 提交于
Use HTTPS where possible to avoid plaintext HTTP connections.
-
由 Manish Goregaokar 提交于
@mahkoh points out in #15628 that unicode.py does not use normative data for Grapheme classes. This pr fixes that issue, and does some minor cleanup of the unicode.py script. In addition, GC_RegionalIndicator is renamed GC_Regional_Indicator in order to stay in line with the Unicode class name definitions. I have updated refs in u_str.rs, and verified that there are no refs elsewhere in the codebase. However, in principle someone using the unicode tables for their own purposes might see breakage from this.
-
由 Tero Hänninen 提交于
-
由 bors 提交于
-
由 Manish Goregaokar 提交于
-
- 07 4月, 2015 22 次提交
-
-
由 Manish Goregaokar 提交于
* Fix broken \"module-level documentation\" link on the [`trait Any` docs](http://doc.rust-lang.org/std/any/trait.Any.html) and related broken markup on the [`std::any` docs](http://doc.rust-lang.org/std/any/index.html). * Remove an outdated or incorrect notice in the `BufRead::lines` docs. There is no such `read_string` function, and `lines` never returns an error. r? @steveklabnik
-
由 Manish Goregaokar 提交于
traits.md said: If we add a `use` line right above `main` and make the right things public, everything is fine: However, the use line was actually placed at the top of the file instead. Move the use line to right above main. That also makes the example more evocative of cases where the module is defined in a separate file.
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Fixes #24060.
-
由 Manish Goregaokar 提交于
This probably needs a bit more work, but I wanted to try and capture some common use cases and be a bit more helpful. r? @huonw cc @steveklabnik
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Fixes #24030 Of the four code samples with modules in TRPL: - 2 use `mod test` - 2 use `mod tests` We should be consistent here, but which is right? The stdlib is split: $ grep -r 'mod tests {' src/lib* | wc -l 63 $ grep -r 'mod test {' src/lib* | wc -l 58 Subjectively, I like the plural, but both the language reference and the style guide recommend the singular. So we'll go with that here, for now. r? @steveklabnik
-
由 Manish Goregaokar 提交于
cc @steveklabnik
-
由 Luke Gallagher 提交于
-
由 Will 提交于
-
由 bors 提交于
cc @steveklabnik
-
由 Xue Fuqiao 提交于
People use programming language *implementations* like Ruby MRI, CPython, and SpiderMonkey for executing programs.
-
由 Luke Gallagher 提交于
Closes #22560
-
由 bors 提交于
Because the current style for `code` in rustdoc is to prewrap whitespace, code spans that are hard wrapped in the source documentation are prematurely wrapped when rendered in HTML. [For example][2], ``` /// ... /// type can be borrowed as multiple different types. In particular, `Vec<T>: /// Borrow<Vec<T>>` and `Vec<T>: Borrow<[T]>`. ``` renders as ![screen shot 2015-04-06 at 12 11 21](https://cloud.githubusercontent.com/assets/191331/7008216/2706b3b0-dc56-11e4-941e-1b0154fcbc5c.png) because "`Vec<T>: Borrow<Vec<T>>`" wraps to the next line in the source. CommonMark 0.18 [[1]] specifies "interior spaces and line endings are collapsed into single spaces" for code spans, which would actually prevent this issue, but hoedown does not currently conform to the CommonMark spec. The added span-level callback attempts to adhere to how whitespace is handled as described by CommonMark, fixing the issue of early, unintentional wrapping of code spans in rendered HTML. [1]: http://spec.commonmark.org/0.18/ [2]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html
-
由 Nick Cameron 提交于
And fix a bug with type param visibility though the Self rib.
-
由 Xue Fuqiao 提交于
Use HTTPS where possible to avoid plaintext HTTP connections.
-
由 bors 提交于
The current help string ("space separated list") suggests that `--passes "pass1 pass2"` is expected; the orrect usage is `--passes pass1 --passes pass2`.
-
由 Will Hipschman 提交于
Issue #22425
-
由 bors 提交于
This adds the missing methods and turns `str::pattern` in a user facing module, as per RFC. This also contains some big internal refactorings: - string iterator pairs are implemented with a central macro to reduce redundancy - Moved all tests from `coretest::str` into `collectionstest::str` and left a note to prevent the two sets of tests drifting apart further. See https://github.com/rust-lang/rust/issues/22477
-
由 kwantam 提交于
@mahkoh points out in #15628 that unicode.py does not use normative data for Grapheme classes. This pr fixes that issue. In addition, GC_RegionalIndicator is renamed GC_Regional_Indicator in order to stay in line with the Unicode class name definitions. I have updated refs in u_str.rs, and verified that there are no refs elsewhere in the codebase. However, in principle someone using the unicode tables for their own purposes might see breakage from this.
-
由 bors 提交于
Hello! I've been working towards a libsyntax without panics. See: http://internals.rust-lang.org/t/changing-libsyntax-to-use-result-instead-of-panic/1670 This patch changes the internals of parser.rs to use Result<> rather than panicing. It keeps the following old-style panicing functions as a facade: parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt I left these functions because I wasn't sure what to do about the quote_* macros or how many syntax-extensions would break if these and quoting macros returned Result. The gyst of the rest of the patch is: - Functions in parse/parser.rs return PResult<> rather than panicing - Other functions in libsyntax call panic! explicitly if they rely on panicing behaviour. - I added a macro 'panictry!()' to act as scaffolding for callers while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()). Am I on the right track? I'd quite like to get something merged soon as keeping this rebased in the face of libsyntax changes is a lot of work. Please let me know what changes you'd like to see to make this happen. Thanks!, Phil
-
由 bors 提交于
...of #6993. cc @pcwalton
-