Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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

# for free to join this conversation on GitHub. Already have an account? # 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