Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macros: ty matcher doesn't accept trait object types with + (type sums) #39080

Closed
petrochenkov opened this issue Jan 15, 2017 · 2 comments · Fixed by #40043
Closed

macros: ty matcher doesn't accept trait object types with + (type sums) #39080

petrochenkov opened this issue Jan 15, 2017 · 2 comments · Fixed by #40043
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)

Comments

@petrochenkov
Copy link
Contributor

Code:

macro_rules! m {
    ($t: ty) => ()
}

fn main() {
    m!(Write + Send);
}

Expected result: code compiles.

Actual result:

rustc 1.16.0-nightly (1a2ed98d3 2017-01-13)
error: no rules expected the token `+`
 --> <anon>:6:14
  |
6 |     m!(Write + Send);
  |              ^
@petrochenkov
Copy link
Contributor Author

Workaround:

m!((Write + Send));

bors added a commit that referenced this issue Jan 17, 2017
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 #39085 (comment) and #39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.

r? @eddyb
@brson
Copy link
Contributor

brson commented Jan 19, 2017

cc @pnkfelix @nrc

@brson brson added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) I-wrong labels Jan 19, 2017
@petrochenkov petrochenkov self-assigned this Feb 19, 2017
bors added a commit that referenced this issue Mar 22, 2017
Refactor parsing of trait object types

Bugs are fixed and code is cleaned up.

User visible changes:
- `ty` matcher in macros accepts trait object types like `Write + Send` (#39080)
- Buggy priority of `+` in trait object types starting with `for` is fixed (#39317). `&for<'a> Trait<'a> + Send` is now parsed as `(&for<'a> Trait<'a>) + Send` and requires parens `&(for<'a> Trait<'a> + Send)`. For comparison, `&Send + for<'a> Trait<'a>` was parsed like this since [Nov 27, 2014](#19298).
- Trailing `+`s are supported in trait objects, like in other bounds.
- Better error reporting for trait objects starting with `?Sized`.

Fixes #39080
Fixes #39317 [breaking-change]
Closes #39298
cc #39085 (fixed, then reverted #40043 (comment))
cc #39318 (fixed, then reverted #40043 (comment))

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants