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
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
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).
Auto merge of #23938 - nikomatsakis:invariant, r=pnkfelix
There are still some remnants we could remove from the compiler (e.g. references to "subtraitrefs"; traits still have variance entries in the variance table), but this removes all user-visible bits I believe.
r? @pnkfelix
Fixes #22806 (since such traits would no longer exist)
Auto merge of #23832 - petrochenkov:usize, r=aturon
These constants are small and can fit even in `u8`, but semantically they have type `usize` because they denote sizes and are almost always used in `usize` context. The change of their type to `u32` during the integer audit led only to the large amount of `as usize` noise (see the second commit, which removes this noise).
This is a minor [breaking-change] to an unstable interface.
projects / rust.git / log