Auto merge of #24021 - pnkfelix:fn-params-outlive-body, r=nikomatsakis
Encode more precise scoping rules for function params
Function params outlive everything in the body (incl temporaries). Thus if we assign them their own `CodeExtent`, the region inference can properly show that it is sound to have temporaries with destructors that reference the parameters (because such temporaries will be dropped before the parameters are dropped).
Auto merge of #24078 - whipsch:extra-token-msg, r=huonw
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.
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`.
Encode more precise scoping rules for function params.
Function params which outlive everything in the body (incl
temporaries). Thus if we assign them their own `CodeExtent`, the
region inference can properly show that it is sound to have
temporaries with destructors that reference the parameters (because
such temporaries will be dropped before the parameters are).
This allows us to address issue 23338 in a clean way.
As a drive-by, fix a mistake in the tyencode for
`CodeExtent::BlockRemainder`.
projects / rust.git / log