Skip to content

Generic associated type constraints are reformatted into broken code #4802

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

Closed
lulf opened this issue Apr 16, 2021 · 3 comments
Closed

Generic associated type constraints are reformatted into broken code #4802

lulf opened this issue Apr 16, 2021 · 3 comments
Labels
bug Panic, non-idempotency, invalid code, etc. needs-test
Milestone

Comments

@lulf
Copy link

lulf commented Apr 16, 2021

Describe the bug

When constraining a generic associated type, rustfmt will remove any parameters for that type. I.e.:

struct MyType<'a, A: MyApi<Assoc<'a> = ()>> {}

will be reformatted to

struct MyType<'a, A: MyApi<Assoc = ()>> {}

To Reproduce

The following code compiles and runs, but when running rustfmt on it it will remove the generics for the associated type:

#![feature(generic_associated_types)]

trait MyApi {
    type Assoc<'a>;
}

struct MyImpl {}

impl MyApi for MyImpl {
    type Assoc<'a> = ();
}

// NOTE: "Assoc<'a> = ()" gets reformatted as "Assoc = ()" when running rustfmt
struct MyType<'a, A: MyApi<Assoc<'a> = ()>> {
    a: A,
    _m: core::marker::PhantomData<&'a A>,
}

fn main() {
    let s = MyImpl {};
    let t = MyType {
        a: s,
        _m: core::marker::PhantomData,
    };
}

Expected behavior

The above code compiles and should not be formatted so it doesn't compile.

Meta

  • rustfmt version: 1.4.37-nightly (0bd2b19 2021-04-03)
  • From where did you install rustfmt?: rustup
  • How do you run rustfmt: rustfmt, cargo fmt
@lulf lulf added the bug Panic, non-idempotency, invalid code, etc. label Apr 16, 2021
@calebcartwright calebcartwright added 1x-backport:pending Fixed/resolved in source but not yet backported to a 1x branch and release needs-test labels Apr 21, 2021
@calebcartwright calebcartwright added this to the 1.4.38 milestone Apr 21, 2021
@calebcartwright
Copy link
Member

Thanks for the report! This has actually already been addressed in source and is just pending release

@wada314
Copy link
Contributor

wada314 commented Jul 23, 2021

Hello, is there any way to try this feature in the today's nightly build?
I tried --config version=Two option but it is still generating the broken code...

Here's a test case I just copy-and-pasted the lulf's sample code, with adding // rustfmt-version: Two:
wada314@d0d72ff
It is still failing as lulf described.

@karyon
Copy link
Contributor

karyon commented Oct 28, 2021

Duplicate of #4943, fix shipped in 1.4.38

@karyon karyon closed this as completed Oct 28, 2021
@karyon karyon removed the 1x-backport:pending Fixed/resolved in source but not yet backported to a 1x branch and release label Oct 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Panic, non-idempotency, invalid code, etc. needs-test
Projects
None yet
Development

No branches or pull requests

4 participants