Bounds parsing refactoring 2
See https://github.com/rust-lang/rust/pull/37511 for previous discussion.
cc @matklad
Relaxed parsing rules:
- zero bounds after `:` are allowed in all contexts.
- zero predicates are allowed after `where`.
- trailing separator `,` is allowed after predicates in `where` clauses not followed by `{`.
Other parsing rules:
- trailing separator `+` is still allowed in all bound lists.
Code is also cleaned up and tests added.
I haven't touched parsing of trait object types yet, I'll do it later.
exclusive range patterns
adds `..` patterns to the language under a feature gate (`exclusive_range_pattern`).
This allows turning
``` rust
match i {
0...9 => {},
10...19 => {},
20...29 => {},
_ => {}
}
```
into
``` rust
match i {
0..10 => {},
10..20 => {},
20..30 => {},
_ => {}
}
```
Fix multiple labels when some don't have message
The diagnostic emitter now accounts for labels with no text message, presenting the underline on its own, without drawing the line for the non existing message below it. Go from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| | |
| | `b` is a good letter
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| |
| `b` is a good letter
```
from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
| `a` is a good letter
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^ `a` is a good letter
```
and from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
```
r? @nikomatsakis
cc @jonathandturner, @GuillaumeGomez, @nrc
They're long dead since the switch to flexible targets, but was not
removed like their consumers were. Interesting they even got maintained
by various porters out there!
Technically [syntax-breaking] as they're public API, but since they're
unused in the compiler, the potential breakage IMO should be minimal.
The diagnostic emitter now accounts for labels with no text message,
presenting the underline on its own, without drawing the line for the
non existing message below it. Go from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| | |
| | `b` is a good letter
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| |
| `b` is a good letter
```
and from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
| `a` is a good letter
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^ `a` is a good letter
```
Refactor the parser to consume token trees
This is groundwork for efficiently parsing attribute proc macro invocations, bang macro invocations, and `TokenStream`-based attributes and fragment matchers.
This improves parsing performance by 8-15% and expansion performance by 0-5% on a sampling of the compiler's crates.
r? @nrc
Implement `#[proc_macro_attribute]`
This implements `#[proc_macro_attribute]` as described in https://github.com/rust-lang/rfcs/pull/1566
The following major (hopefully non-breaking) changes are included:
* Refactor `proc_macro::TokenStream` to use `syntax::tokenstream::TokenStream`.
* `proc_macro::tokenstream::TokenStream` no longer emits newlines between items, this can be trivially restored if desired
* `proc_macro::TokenStream::from_str` does not try to parse an item anymore, moved to `impl MultiItemModifier for CustomDerive` with more informative error message
* Implement `#[proc_macro_attribute]`, which expects functions of the kind `fn(TokenStream, TokenStream) -> TokenStream`
* Reactivated `#![feature(proc_macro)]` and gated `#[proc_macro_attribute]` under it
* `#![feature(proc_macro)]` and `#![feature(custom_attribute)]` are mutually exclusive
* adding `#![feature(proc_macro)]` makes the expansion pass assume that any attributes that are not built-in, or introduced by existing syntax extensions, are proc-macro attributes
* Fix `feature_gate::find_lang_feature_issue()` to not use `unwrap()`
* This change wasn't necessary for this PR, but it helped debugging a problem where I was using the wrong feature string.
* Move "completed feature gate checking" pass to after "name resolution" pass
* This was necessary for proper feature-gating of `#[proc_macro_attribute]` invocations when the `proc_macro` feature flag isn't set.
Prototype/Litmus Test: [Implementation](https://github.com/abonander/anterofit/blob/proc_macro/service-attr/src/lib.rs#L13) -- [Usage](https://github.com/abonander/anterofit/blob/proc_macro/service-attr/examples/post_service.rs#L35)
Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring
`ObjectSum` and `PolyTraitRef` are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them.
The first commit replaces `Path` with `Ty` in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality.
The third commit uses `Vec` instead of `P<[T]>` in AST. AST is not immutable like HIR and `Vec`s are more convenient for it, unnecessary conversions are also avoided.
The last commit renames `parse_ty_sum` (which is used for parsing types in general) into `parse_ty`, and renames `parse_ty` (which is used restricted contexts where `+` is not permitted due to operator priorities or other reasons) into `parse_ty_no_plus`.
This is the first part of https://github.com/rust-lang/rust/issues/39085#issuecomment-272743755 and https://github.com/rust-lang/rust/issues/39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.
r? @eddyb
* Add support for `#[proc_macro]`
* Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it
* Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`,
error on legacy import of proc macros via `#[macro_use]`
