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

Breaking change in macro_rules ty fragment parsing in version 1.68 #107796

Closed
zakarumych opened this issue Feb 8, 2023 · 4 comments · Fixed by #107813
Closed

Breaking change in macro_rules ty fragment parsing in version 1.68 #107796

zakarumych opened this issue Feb 8, 2023 · 4 comments · Fixed by #107813
Assignees
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-beta Performance or correctness regression from stable to beta.

Comments

@zakarumych
Copy link
Contributor

zakarumych commented Feb 8, 2023

I tried this code:

macro_rules! impl_primitive {
    ($ty:ty) => { impl_primitive!(impl $ty);};
    (impl $ty:ty) => { fn a(_: $ty) {} }
}

impl_primitive! { u8 }

link to playground

I expected to see this happen:
Macro is expanded to fn a(_: u8) {}

Instead, this happened:
On stable 1.67 it works as expected.
On beta 1.68 and nightly 1.69 it fails with the following error

error: expected a trait, found type
 --> src/lib.rs:6:19
  |
2 |     ($ty:ty) => { impl_primitive!(impl $ty);};
  |      ------ while parsing argument for this `ty` macro fragment
...
6 | impl_primitive! { u8 }
  |                   ^^

It is probably caused by ty fragment that now treats impl as a start of impl Trait type.
So makes sense. But breaks existing code :)

@zakarumych zakarumych added the C-bug Category: This is a bug. label Feb 8, 2023
@Dylan-DPC Dylan-DPC added the regression-from-stable-to-beta Performance or correctness regression from stable to beta. label Feb 8, 2023
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 8, 2023
@compiler-errors
Copy link
Member

searched nightlies: from nightly-2022-06-01 to nightly-2023-02-01
regressed nightly: nightly-2023-01-18
searched commit range: 4781233...3984bc5
regressed commit: 85357e3

bisected with cargo-bisect-rustc v0.6.4

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --access github --timeout 30 --start 2022-06-01 --end 2023-02-01 --regress error 

I think I see where the issue is, I'll fix it.

@rustbot claim

@apiraino
Copy link
Contributor

apiraino commented Feb 8, 2023

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Feb 8, 2023
compiler-errors added a commit to compiler-errors/rust that referenced this issue Feb 9, 2023
…macro-is-ok, r=estebank

Do not eagerly recover for bad `impl Trait` types in macros

Fixes rust-lang#107796

cc rust-lang#106712, `@estebank` and `@Ezrashaw` please make sure to use [`Parser::may_recover`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.may_recover) for all eager-token-consuming parser recoveries.

This also fixes a separate regression from rust-lang#99915, that was introduced before we added `may_recover` though.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Feb 9, 2023
…macro-is-ok, r=estebank

Do not eagerly recover for bad `impl Trait` types in macros

Fixes rust-lang#107796

cc rust-lang#106712, ``@estebank`` and ``@Ezrashaw`` please make sure to use [`Parser::may_recover`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.may_recover) for all eager-token-consuming parser recoveries.

This also fixes a separate regression from rust-lang#99915, that was introduced before we added `may_recover` though.
@bors bors closed this as completed in ab09405 Feb 9, 2023
@apiraino
Copy link
Contributor

apiraino commented Feb 9, 2023

IIRC issues with a backport pending should stay open to track the backport process (not 100% sure tho)

@apiraino apiraino reopened this Feb 9, 2023
@apiraino
Copy link
Contributor

beta backport in #108037

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-beta Performance or correctness regression from stable to beta.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants