Tracking Issue for item-level `const` blocks

[GrigorenkoPV]

There has been no RFC, afaict. However, t-lang have expressed enthusiasm about seeing this added.
The feature gate for the issue is #![feature(const_block_items)].

Currently, this feature allows you to write const blocks as items in modules. So, it makes the following code possible:

#![feature(const_block_items)]

const {
    let a = 2 + 2;
    assert!(a != 5)
}

fn main() { }

Which is equivalent to the current stable's:

const _: () = {
    let a = 2 + 2;
    assert!(a != 5)
};
fn main() { }

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

• See also: Lang discussion: Item-level const {} blocks, and const { assert!(...) } lang-team#251

Steps

• Implementation
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• RFC needed?
• it has been decided that module-level const { ... } item is equivalent to const _: () =, but what about statement-items (i.e. inside function body) or assoc items?
• Making const { ... } sometimes an item and sometimes an expression complicates our story about that.
  • Other possibilities would be things like const _ = ...; to clarify that it's an item, but shorten the syntax (like one can omit -> () on functions)
• The diagnostics for module-level const block items are subpar, and could benefit from
  • mentioning that the return type of the block is expected to be ()
  • actually having the phrase "const block item" in messages instead of "malformed const"
  • not leaking the dummy _ identifiers that are inserted during AST->HIR lowering of const { ... } to const _: () = const { ... };
  • rejecting visibility qualifiers on module-level const block items, since those have no effect (see also: Add warn-by-default lint for visibility on const _ declarations #147136)

Implementation history

• Module-level const blocks: const blocks as a mod item #149174

[tgross35]

Could you add a small summary and demo to the issue? It's not clear what this is about or what it is supposed to look like without doing a bit of digging in the implementation PR.