Tracking Issue for `#[global_registration]`

[jdonszelmann]

This is a tracking issue for the global registration experiment. The feature gate for the issue is #![feature(global_registration)].

Global registration has previously been discussed on internals.rust-lang.org and a proposal was made on the testing devex team with @epage . Specific syntax has not been discussed yet, which is part of what this experiment is going to figure out. Likely, a first implementation will use built-in attribute macros.

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.

Steps

• [ ] Get lang experiment approved. (@scottmcm is liaisoning me)
• [ ] Land the experimental implementation in nightly.
  • [x] Experimental feature flag: #125314 (now available on nightly)
  • [x] Update core/std with a new global_registration module (implemented on forked branch)
  • [x] Add new built-in macros to rust to create and add to global registries (implemented on forked branch)
  • [x] Propagate global registries through the AST and HIR, also performing name resolution (implemented on forked branch)
  • [ ] Write docs for core::global_registration
  • [ ] Check whether #[global_registry] defenitions have the right wrapper type (Registry<T>)
  • [ ] Actually create nice errors instead of panicking in unexpected cases
  • [ ] tests for
    • [ ] errors generated
    • [ ] doc(alias) (not entirely sure about my current implementation, so test that)
    • [ ] the right has_codegen_attrs, I'm not sure I did that right
    • [ ] privacy of global registries
  • [ ] Add global registries to RustDoc
  • [ ] Check if my sym::anon in definition.rs is correct
• [ ] Accept an RFC
• [ ] Adjust documentation (see instructions on rustc-dev-guide)
• [ ] Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• [ ] Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

TODO

Implementation history

TODO

Current proposed syntax

use core::global_registration::{global_registry, register, Registry};

#[global_registry]
static ERROR_MSGS: Registry<&str>;

register!(ERROR_MSGS, "a");
register!(ERROR_MSGS, "b", "c");

fn main() {
    for msg in ERROR_MSGS {
        println!("{}", msg);
    }
}

[jdonszelmann]

@rustbot label +F-global_registration +T-lang

[camsteffen]

Another use case: I think Clippy could use this to register more Symbol constants like sym::*.

[bjorn3]

You did have to be careful to ensure that the crate metadata encoder doesn't consider those extra symbol constants as preinterned, otherwise rustc won't be able to decode metadata generated by clippy. Also clippy uses rustc as dylib, so for clippy to use #[global_registration] dylibs would have to be supported.

[Indra-db]

A potential use case for this could be to is assign meta data to a type.

In my particular use case, assigning an id / index "static" to each type.

Currently Rust doesn't support generic statics due to issues on windows with dylib, but this could potentially be used instead? Would global registration allow for such use case?

See relevant discussion (before and after) here: https://discord.com/channels/273534239310479360/592856094527848449/1246014749288955945

[T-Dark0]

To elaborate a bit, as I was in that discussion:

The goal here is to generate a per-type identifier that, for FFI/stability reasons, cannot be TypeId. This identifier also needs to consider different instantiations of the same generic type to be different types, and must be generated at runtime, which rules out doing this in const

The C++ way of doing this is approximately equivalent to a OnceLocked local static variable inside a function of a template class, which causes the variable to be duplicated per instantiation of the template class. This doesn't work in Rust, as the local static will, just like all local items do, behave as if it had been written at the top scope in all except its own scope.

The idea here, from our discussion, is to ensure that register!, or whatever replaces it in the eventual syntax, can be called from inside a monomorphised function, and behaves more like an expression than an item, allowing it, and its "initializers" (assuming a syntax like register!(registry, initializers)), to access generics from the enclosing scope much like const {} blocks, and performing one registration per instantiation.