Skip to content

Generic associated type constraints are reformatted into broken code #4802

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
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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Panic, non-idempotency, invalid code, etc. needs-test
Projects
None yet
Development

No branches or pull requests

4 participants