Thanks for the report. Any chance you could link me to more info about #![feature(dyn_star)]?

I can confirm that I'm able to reproduce the issue on the playground, however when running with the latest master (ef91154) this is the output that I get:

#![feature(dyn_star)]
#![allow(incomplete_features)]

use core::fmt::Debug;

fn main() {
    let i = 42;
    let dyn_i = i as dyn * Debug;
    dbg!(dyn_i);
}

Any chance you could link me to more info about #![feature(dyn_star)]?

It was introduced with rust-lang/rust#101212

however when running with the latest master (ef91154) this is the output that I get

Ah if it's fixed already that's great. 🙂

Thanks for linking the dyn* PR. It looks like that PR didn't make changes to handle dyn* formatting in rustfmt, so I don't think it's fixed yet. Also the dyn* Debug from your original snippet is getting converted to dyn * Debug. Not sure if things still compile when formatted like that, but it looks like there's still work to do on the rustfmt side to support dyn*.

dyn* Debug and dyn * Debug will both parse and compile fine, but I prefer the dyn* version.

I took a look at this again. The latest rustfmt master is using nightly-2022-08-06, which doesn't know about the new ast::TraitObjectSyntax::DynStar variant. In the example I mentioned above #5542 (comment) it turns out the current master parses i as dyn* Debug as a binary multiplication where the lhs is i as dyn and the rhs is Debug. At least that's my understanding of why i as dyn* Debug was formatted as i as dyn * Debug.

In order to resolve this we'll need to do a subtree sync with r-l/rust. @calebcartwright usually handles those, and from what I understand we're waiting for a few PRs to land in r-l/rust before performing the sync.

Changes will ultimately need to be made to the ast::TyKind::TraitObject arm in the Rewrite impl for ast::Ty to properly handle the ast::TraitObjectSyntax::DynStar variant added in rust-lang/rust#101212 .

The fix should be pretty straightforward once we've done the sync.