Type ascription builtin is silently replaced by rustfmt(?)

[Mark-Simulacrum]

rustfmt complains about the type_ascribe macro asking for the builtin to be replaced with the ... : ... syntax:

Error: Diff in /checkout/library/core/src/macros/mod.rs at line 1712:
         reason = "placeholder syntax for type ascription"
     )]
     pub macro type_ascribe($expr:expr, $ty:ty) {
-        builtin # type_ascribe($expr, $ty)
+        $expr: $ty
     }

I've worked around this with #[rustfmt::skip] on the macro which seems to work, but filing an issue since it seems like somewhat odd behavior as well.

[Noratrieb]

looks like rustfmt wasn't updated to print type ascription correctly, this issue should be removed to the rustfmt repo probably

[ytmimi]

@Mark-Simulacrum The diff is helpful, but can you also provide a complete code snippet that we can use to reproduce the issue. A few more questions. What version of rustfmt were you using when you ran into this issue, and are you using any rustfmt configurations?

[ytmimi]

@Nilstrieb do you know how builtin # type_ascribe is represented in the AST?

for example, builtin # offset_of is represented by rustc_ast::ast::ExprKind::OffsetOf

[ytmimi]

@Nilstrieb @Mark-Simulacrum Okay, I think the issue here is that builtin # type_ascribe gets parsed as rustc_ast::ast::ExprKind::Type.

From what I can tell Here's where this get's parsed in rustc.

In this case rustfmt is handling this as expected. It sees a ExprKind::Type in the ast and outputs one. I think this issue should be moved back to rust-lang/rust and the fix probably involves creating some special builtin ast node, though I don't know enough about later phases of the compiler to know how that might complicate things after parsing.

[Noratrieb]

haha, looks like ast_pretty wasn't correctly updated then, fun. I don't think any AST changes are needed, it just needs to print the ExprKind::Type with the builtin syntax.

[ytmimi]

@Nilstrieb Do you have thoughts on how rustfmt can tell the difference between builtin # type_ascribe and expr: ty if they both get parsed as ExprKind::Type?

[Noratrieb]

the latter does not exist anymore

[ytmimi]

If ExprKind::Type exclusively represents builtin # type_ascrib then I agree we don't need to make any ast changes. Do you know when the switch from expr: ty -> builtin # type_ascribe occurred? Maybe we should also update the doc comment on ExprKind::Type to explain that as well.

[Noratrieb]

It was implemented by Yukang and me, with the biggest change in rust-lang/rust#109128

[ytmimi]

Thanks for the link!

[fmease]

And rust-lang/rust#122806 made the macro type_ascribe use builtin # type_ascribe.

[fmease]

rustc_ast_pretty does print builtin # offset_of and builtin # type_acribe correctly (well, it prints builtin # type_ascribe as type_ascribe! but I'm gonna fix that, too), only rustfmt doesn't. rustfmt actually crashes on builtin # offset_of.

Working on a patch for rust-lang/rustfmt, let's see if I can make it work.

[ytmimi]

rustc_ast_pretty does print builtin # offset_of and builtin # type_acribe correctly (well, it prints builtin # type_ascribe as type_ascribe! but I'm gonna fix that, too), only rustfmt doesn't. rustfmt actually crashes on builtin # offset_of.

Working on a patch for rust-lang/rustfmt, let's see if I can make it work.

Nice! I think you can just move the ExprKind::Type to the same match arm as ExprKind::OffsetOf in rust-lang/rustfmt

Though we haven't done a sync in a while so I'm not sure if we've pulled in some of the more recent changes in rustfmt yet.

[fmease]

Moving it back to the rustfmt repo since this is strictly rustfmt-related (wrong output for type_ascribe, panic on offset_of) as AST pretty works perfectly fine.

@rustbot transfer rustfmt

[rustbot]

Error: The feature transfer is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[Noratrieb]

someone needs to make a PR for that :D

[fmease]

@rustbot transfer rustfmt

[ytmimi]

After the latest subtree sync, and starting with nightly-2024-06-24, this issue should be resolved.

Using nightly-2024-06-23 still has the issue

Using nightly-2024-06-24 fixes the issue