rust/src/libsyntax/parse, 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.
Don't compute padding of braces unless they are unmatched2018-09-09T21:55:46+00:00Esteban Küberesteban@kuber.com.ar2018-09-09T21:55:46+00:00urn:sha1:014a56ca9c0ad4b0ab1e377a66236242b4329413Auto 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:a1dd39e724c2a37f08f534e90ced134d38a49417Auto merge of #53949 - estebank:unclosed-delim, r=nikomatsakis2018-09-09T01:36:58+00:00borsbors@rust-lang.org2018-09-09T01:36:58+00:00urn:sha1:004bc5a33cd44cd0896cae917a75488579126da5
Improve messages for un-closed delimiter errors
Change wording of unclosed delimiter label2018-09-05T14:33:29+00:00Esteban Küberesteban@kuber.com.ar2018-09-05T14:33:29+00:00urn:sha1:3192d3dc0c4417a6e360018b341c07d32f3f3d7fProvide more context for unenclosed delimiters2018-09-05T10:43:24+00:00Esteban Küberesteban@kuber.com.ar2018-09-04T15:09:49+00:00urn:sha1:008aa5a24e152691d852bd9f0a2990b6e4377397
* When encountering EOF, point at the last opening brace that does not
have the same indentation level as its close delimiter.
* When encountering the wrong type of close delimiter, point at the
likely correct open delimiter to give a better idea of what went
wrong.
Reword un-closed delimiter label2018-09-05T10:43:24+00:00Esteban Küberesteban@kuber.com.ar2018-08-27T00:22:36+00:00urn:sha1:5238b523c3959e33add469af77b2ffa5a60b4cf6