Ability to omit : () on const item declarations

[GrigorenkoPV]

• Tracking issue: Tracking Issue for item-level const blocks #149226

As suggested in #149174 (comment), this PR adds an ability to omit : () from const item declarations. If the type is omitted, it defaults to (). This is similar to how function declarations treat -> ().

Implementation details:

• The gate is #![feature(const_items_unit_type_default)] with the same tracking issue as for #![feature(const_block_items)]
• ast::ConstItem's ty is changed from Box<ast::Ty> into ast::FnRetTy, which is like an Option<Box<Ty>> but with a Span for the None variant.
• During parsing:
  • static items with unspecified type still give an error, just as before
  • const items with an unspecified type no longer give the previous error, but instead demand that you have the new feature enabled and fallback to : ().
• During AST->HIR lowering:
  • const items with no type specified in AST get a () in HIR
• rustfmt support included

TODO:

• Sadly, it seemes like it undoes the internal compiler error: missing type for const item #69396. Maybe instead of falling back to : (), fallback to : _ (as it was before) when the feature is not enabled?
• make a separate tracking issue or update Tracking Issue for item-level const blocks #149226
• is the feature gate name ok?
• do not reuse FnRetTy or rename it?
• do the "unspecified means ()" substitution not during AST->HIR, but later on?
• allow to omit : () for static items too? for consistency. despite static: () being kinda useless.
• better diagnostic messages?

[GrigorenkoPV]

CC @joshtriplett as the lang champion

[bors]

☔ The latest upstream changes (presumably #149891) made this pull request unmergeable. Please resolve the merge conflicts.

[rust-bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

[rustbot]

r? @tiif

rustbot has assigned @tiif.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tiif]

This PR is out of my comfort zone.

r? @jdonszelmann

since you reviewed the previous PR :)

(also I suppose this also needs approval from rustfmt and clippy? not sure what is the best course of action here, I will leave it to the next reviewer to judge.)

[Centri3]

Clippy changes look good to me.
Cool PR in my opinion

View changes since this review

[jdonszelmann]

@joshtriplett @scottmcm at the very least this needs lang approval. Scott seems to have suggested this. I think I'm very much against it: if the plan is to have toplevel const{} blocks, I don't see why we need this, and I think that leaving out types here is very inconsisten. I know this is what functions do, but I really don't think I like this for consts. Especially since returning () from functions is super common, but assigning them to consts is not except this case that we're already trying to simplyfy as a top-level const block. I'm not on T-lang, but I would object to it if I were.

[jdonszelmann]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[scottmcm]

if the plan is to have toplevel const{} blocks

If that's the plan, then I'd agree, but I'm skeptical of that plan because that makes them behave differently in different places without any syntax difference. I worry about things no longer doing what people wanted because they move a const block from item context to expression context.

My suggestion was as a possible alternative to item-context const blocks. I don't know what overall lang thinks of that.

[GrigorenkoPV]

Then I guess an opinion from T-lang is needed.

@rustbot label +I-lang-nominated +S-waiting-on-t-lang -S-waiting-on-author