@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.
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or `unsafe
extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Fixes#24161.
Statement macros are now treated somewhat like item macros, in that a
statement macro can now expand into a series of statements, rather than
just a single statement.
This allows statement macros to be nested inside other kinds of macros and
expand properly, where previously the expansion would only work when no
nesting was present.
See: src/test/run-pass/macro-stmt_macro_in_expr_macro.rs
src/test/run-pass/macro-nested_stmt_macro.rs
This changes the interface of the MacResult trait. make_stmt has become
make_stmts and now returns a vector, rather than a single item. Plugin
writers who were implementing MacResult will have breakage, as well as
anyone using MacEager::stmt.
See: src/libsyntax/ext/base.rs
This also causes a minor difference in behavior to the diagnostics
produced by certain malformed macros.
See: src/test/compile-fail/macro-incomplete-parse.rs
* 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
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.
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
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.
[1]: http://spec.commonmark.org/0.18/
[2]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html
The current help string ("space separated list") suggests that `--passes "pass1 pass2"` is expected; the orrect usage is `--passes pass1 --passes pass2`.
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
This allows `io::Error` values to be stored in `Arc` properly.
Because this requires `Sync` of any value passed to `io::Error::new()`
and modifies the relevant `convert::From` impls, this is a
[breaking-change]
Fixes#24049.
@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.
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
Since it doesn't utilize the parameter, it's not very idiomatic since it
could just use the `Result::or` method. So this changes the example to
utilize the parameter. As far as I can tell, all the numbers in this
example are completely arbitrary.
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.
[1]: http://spec.commonmark.org/0.18/
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 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.
