rust/src/libsyntax/parse/parser.rs, branch 1.30.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.30.02018-09-14T23:05:32+00:00issue 54109: use short suggestions2018-09-14T23:05:32+00:00Vitaly _Vi Shukelavi0oss@gmail.com2018-09-14T23:05:32+00:00urn:sha1:bc63a4a13a442e1844bb5577adcc464c2a6bfd21Use span_suggestion_with_applicability for "and/or" hinter2018-09-13T17:44:07+00:00Vitaly _Vi Shukelavi0oss@gmail.com2018-09-13T17:40:39+00:00urn:sha1:acc44e40ccd860a3cae54c7b56956c3c1340182e
Advised by @estebank.
Suggest && and || instead of 'and' and 'or'2018-09-13T12:54:12+00:00Vitaly _Vi Shukelavi0oss@gmail.com2018-09-13T12:54:12+00:00urn:sha1:636f518aac7430406dcb410cd7e46b4a217c265c
Closes #54109.
Auto merge of #53902 - dtolnay:group, r=petrochenkov2018-09-09T13:27:44+00:00borsbors@rust-lang.org2018-09-09T13:27:44+00:00urn:sha1:40fc8ba5f95125f307ef17f11ec02b3f5fdad562
proc_macro::Group::span_open and span_close
Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation:
```rust
mod m {
type T =
}
```
```console
error: expected type, found `}`
--> src/main.rs:3:1
|
3 | }
| ^
```
On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above.
This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476.
```diff
impl Group {
fn span(&self) -> Span;
+ fn span_open(&self) -> Span;
+ fn span_close(&self) -> Span;
}
```
Fixes #48187
r? @alexcrichton
Track distinct spans for open and close delimiter2018-09-09T02:01:48+00:00David Tolnaydtolnay@gmail.com2018-09-09T01:07:02+00:00urn:sha1:a1dd39e724c2a37f08f534e90ced134d38a49417Move #[test_case] to a syntax extension2018-09-05T05:33:23+00:00John Rennerjohn@jrenner.net2018-09-02T16:03:24+00:00urn:sha1:0593dc7e3c9783f1c0bbbc8f017f9e914114e057Replace check() + bump() with eat()2018-09-02T06:19:28+00:00Seiichi Uchidaseuchida@gmail.com2018-09-02T06:13:29+00:00urn:sha1:51dbb024f77a2a05921bdef7f07ee66831e48ad8Auto merge of #53815 - F001:if-let-guard, r=petrochenkov2018-09-01T20:31:29+00:00borsbors@rust-lang.org2018-09-01T20:31:29+00:00urn:sha1:28bcffead74d5e17c6cb1f7de432e37f93a6b50c
refactor match guard
This is the first step to implement RFC 2294: if-let-guard. Tracking issue: https://github.com/rust-lang/rust/issues/51114
The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers.
r? @petrochenkov
Rollup merge of #53655 - jcpst:with_applicability, r=estebank2018-08-30T18:15:33+00:00Pietro Albinipietro@pietroalbini.org2018-08-30T18:15:33+00:00urn:sha1:1535075b58bc725ea71dc0103bda5b840632e957
set applicability
Update a few more calls as described in #50723
r? @estebank
introduce Guard enum2018-08-30T04:18:11+00:00F001changchun.fan@qq.com2018-08-30T04:18:11+00:00urn:sha1:7a083ca25f14833d704d2efba5ca9b431f6c65ad