Rollup merge of #24132 - kwantam:master, r=alexcrichton
@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.
Rollup merge of #24113 - mbrubeck:doc-edit, r=steveklabnik
* 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.
Rollup merge of #24112 - joshtriplett:patch-1, r=steveklabnik
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.
Auto merge of #24116 - zaeleus:rustdoc-codespan, r=alexcrichton
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
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.
Auto merge of #24101 - remram44:fix-rustdoc-passes-help, r=nikomatsakis
The current help string ("space separated list") suggests that `--passes "pass1 pass2"` is expected; the orrect usage is `--passes pass1 --passes pass2`.
Auto merge of #23952 - Kimundi:more_string_pattern, r=alexcrichton
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
@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.
Auto merge of #23857 - phildawes:libsyntax_nopanic, r=nikomatsakis
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.
Michael Macias [Mon, 6 Apr 2015 17:06:39 +0000 (12:06 -0500)]
rustdoc: Add a custom callback for codespan to collapse whitespace
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.
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.
Auto merge of #24056 - nikomatsakis:issue-23853-crates-io, r=aturon
If we find a blanket impl for `Trait` but we're matching on an object `Trait`, prefer the object (I think we could perhaps go either way, but this seems safer). Also give a nice error for attempts to manually `impl Trait for Trait`, since they will be ineffectual.
This fixes the problems around ambiguity ICEs relating to `Any` and `MarkerTrait` that were cropping up all over the place. There may still be similar ICEs reported in #21756 that this PR does not address.
Fixes #24015.
Fixes #24051.
Fixes #24037.
Fixes #23853.
Fixes #21942.
cc #21756.
cc @alexcrichton (this fixes crates.io)
r? @aturon
traits.md: Fix example of using traits to match description
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.
Niko Matsakis [Sat, 4 Apr 2015 09:42:24 +0000 (05:42 -0400)]
If we find a blanket impl for `Trait` but we're matching on an object
`Trait`, prefer the object. Also give a nice error for attempts to
manually `impl Trait for Trait`, since they will be ineffectual.
Fixes #24015.
Fixes #24051.
Fixes #24037.
Fixes #23853.
Fixes #21942.
cc #21756.
The current help string ("space separated list") suggests that
`--passes "pass1 pass2"` is expected; the correct usage is
`--passes pass1 --passes pass2`.
Marvin Löbel [Sun, 15 Mar 2015 00:48:34 +0000 (01:48 +0100)]
Implemented remaining string pattern iterators.
- Added missing reverse versions of methods
- Added [r]matches()
- Generated the string pattern iterators with a macro
- Added where bounds to the methods returning reverse iterators
for better error messages.
Phil Dawes [Sat, 28 Mar 2015 21:58:51 +0000 (21:58 +0000)]
Work towards a non-panicing parser (libsyntax)
- Functions in parser.rs return PResult<> rather than panicing
- Other functions in libsyntax call panic! explicitly for now if they rely on panicing behaviour.
- 'panictry!' macro added as scaffolding while converting panicing functions.
(This does the same as 'unwrap()' but is easier to grep for and turn into try!())
- Leaves panicing wrappers for the following functions so that the
quote_* macros behave the same:
- parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
Auto merge of #23987 - liammonahan:master, r=Manishearth
I ran across a comma splice.
I didn't set the "note:" off inside parenthesis. I looked around in other places and saw it both ways, but without surrounding parenthesis seemed to be the more common convention followed elsewhere in the docs. Let me know if you have an overriding preference about that and I'll change it.
Auto merge of #23981 - chastell:book_crates-and-modules_io_sync, r=Manishearth
This syncs the _Crates and Modules_ chapter of the book with current output:
* the runs are supposed to be in the project’s directory,
* `rustc` has slightly different error messages (and things like macro line:col numbers),
* Cargo now compiles things into `target/debug`.
Rollup merge of #23990 - dhuseby:bitrig_fixing_jemalloc_config, r=alexcrichton
Until I can figure out the correct way to configure jemalloc for Bitrig, this patch will correctly disable it. All other build targets remain unchanged.
Rollup merge of #24005 - ranma42:macosx-no-javac-popup, r=alexcrichton
MacOS X does not ship with Java installed by default. Instead it
includes binary stubs that upon execution pop up a message suggesting
the installation of the JDK.
Since `javac` is only used when `antlr4` is available, it is possible
to work around the popup by only probing for `javac` if `antlr4` has
been successfully detected (in which case the JDK is probably already
installed on the system).
Auto merge of #23972 - gkoz:partial_eq_str_string, r=alexcrichton
Right now comparing a `&String` (or a `&Cow`) to a `&str` requires redundant borrowing of the latter. Implementing `PartialEq<str>` tries to avoid this limitation.
```rust
struct Foo (String);
fn main () {
let s = Foo("foo".to_string());
match s {
Foo(ref x) if x == &"foo" => println!("foo!"),
// avoid this -----^
_ => {}
}
}
```
I was hoping that #23521 would solve this but it didn't work out.
Auto merge of #23930 - petrochenkov:issue23656, r=nrc
Fixes #22757
Fixes #22972
Fixes #23044
Fixes #23151
Fixes #23597
Fixes #23656
Fixes #23929
It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after `...`.
It passes `make check` but needs some additional tests (then it will fix #22546 as well), I'll write them today or tomorrow.
Andrea Canciani [Fri, 3 Apr 2015 13:05:54 +0000 (15:05 +0200)]
Workaround `javac` popup on MacOS X
MacOS X does not ship with Java installed by default. Instead it
includes binary stubs that upon execution pop up a message suggesting
the installation of the JDK.
Since `javac` is only used when `antlr4` is available, it is possible
to work around the popup by only probing for `javac` if `antlr4` has
been successfully detected (in which case the JDK is probably already
installed on the system).
projects / rust.git / log