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

Handle dyn* syntax when rewriting ast::TyKind::TraitObject #5552

Merged
merged 1 commit into from
Jul 28, 2023

Conversation

ytmimi
Copy link
Contributor

@ytmimi ytmimi commented Sep 30, 2022

Resolves #5542

Prior to rust-lang/rust#101212 the ast::TraitObjectSyntax enum only had two variants Dyn and None. The PR that introduced the dyn* syntax added a new variant DynStar, but did not update the formatting rules to account for the new variant.

Now the new DynStar variant is properly handled and is no longer removed by rustfmt.

@ytmimi
Copy link
Contributor Author

ytmimi commented Sep 30, 2022

PR on hold until we do a subtree sync and bump the nighty compiler version to one that supports parsing dyn* syntax.

@ytmimi ytmimi added blocked Blocked on rustc, an RFC, etc. and removed pr-on-hold labels Sep 30, 2022
@calebcartwright
Copy link
Member

The other thing that's needed is input from the style team relative to how these should be formatted, or at least how we think they should be. Wheels are in motion there

Copy link
Member

@calebcartwright calebcartwright left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tentative approval as while I believe this is the direction we'll go, it will still need some level of confirmation first

src/types.rs Outdated
let shape = if is_dyn { shape.offset_left(4)? } else { shape };
let shape = match tobj_syntax {
ast::TraitObjectSyntax::Dyn => shape.offset_left(4)?, // 4 is offset 'dyn '
ast::TraitObjectSyntax::DynStar => shape.offset_left(5)?, // 5 is offset 'dyn* '
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm now that I'm thinking about it would it just be better to return None if we get to a DynStart since its experimental syntax?

@calebcartwright
Copy link
Member

Let's do a simple update to ensure rustfmt stops butchering the syntax altogether, but we should hold off on applying formatting for now. This was a topic in recent t-style discussions, but style/formatting rules are being deferred due to other priorities and focus areas

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna bump this because I almost actually just put up my own PR that duplicated this 🤣.

Per nightly style policy, I'm pretty sure that rustfmt can now feel free to begin formatting dyn* more than just ignoring it altogether. Speaking as an individual on T-style, I think treating dyn* as a single token is what we want to do here anyways.

src/types.rs Outdated
Comment on lines 679 to 682
match tobj_syntax {
ast::TraitObjectSyntax::Dyn => Some(format!("dyn {}", res)),
ast::TraitObjectSyntax::DynStar => Some(format!("dyn* {}", res)),
ast::TraitObjectSyntax::None => Some(res),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only nit is that this could be merged into a single match with above,

something like:

let (shape, prefix) = match tobj_syntax {
    ast::TraitObjectSyntax::Dyn => (shape.offset_left(4)?, "dyn "),
    ast::TraitObjectSyntax::DynStar => (shape.offset_left(5)?, "dyn* "),
    ast::TraitObjectSyntax::None => (shape, ""),
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be happy to make this change since it simplifies the code!

Resolves 5542

Prior to rust-lang/rust#101212 the `ast::TraitObjectSyntax` enum only
had two variants `Dyn` and `None`. The PR that introduced the `dyn*`
syntax added a new variant `DynStar`, but did not update the formatting
rules to account for the new variant.

Now the new `DynStar` variant is properly handled and is no longer
removed by rustfmt.
@ytmimi
Copy link
Contributor Author

ytmimi commented Jul 23, 2023

@compiler-errors I made your suggest change. @calebcartwright does your earlier review still apply?

@calebcartwright calebcartwright added release-notes Needs an associated changelog entry and removed blocked Blocked on rustc, an RFC, etc. pr-not-reviewed labels Jul 28, 2023
@calebcartwright calebcartwright merged commit cdfa2f8 into rust-lang:master Jul 28, 2023
@ytmimi ytmimi removed the release-notes Needs an associated changelog entry label Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rustfmt eats dyn_star syntax
3 participants