-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Allow inline consts to reference generic params #96557
Conversation
r? @cjgillot (rust-highfive has picked a reviewer for you, use r? to override) |
Marking as T-lang as well. @rustbot label: +T-lang |
This comment has been minimized.
This comment has been minimized.
The diagnostics of your tests changed after #96576 as we now display a note at the call site of functions that cause an error after monomorphization You'll need to rebase and rebless. |
r=me with that done. Thanks for doing this, it's been an inconsistency that I've been annoyed at for a year now 😅 |
r? @oli-obk |
You may also want to wait for #96641 before rebasing, as that will just conflict with this PR again. You PR caused me to spawn off two cleanup PRs 😄 (none of them your fault, just things that bugged me before and your PR reminded me of) |
Thanks for doing these PRs! I was annoyed by these as well and was originally tempted to fix them after this PR got merged, but I am glad that I now have less things to do :) Will rebless and rebase later today. |
The generic arg is for type inference only and shouldn't be exposed to users.
@rustbot ready |
@bors r+ |
📌 Commit 6baaa52 has been approved by |
⌛ Testing commit 6baaa52 with merge 23638c523e111b5f70213691e3f9b58a7e7c2443... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@bors r+ |
📌 Commit 5b5ac28 has been approved by |
Allow inline consts to reference generic params Tracking issue: rust-lang#76001 The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo<T>() { let x = [4i32; std::mem::size_of::<T>()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::<T>() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::<T>() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do: ```rust fn assert_zst<T>() { struct F<T>(T); impl<T> F<T> { const V: () = assert!(std::mem::size_of::<T>() == 0); } let _ = F::<T>::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either: ```rust fn foo<T>() -> usize { let (_, size): (PhantomData<T>, usize) = const { const fn my_size_of<T>() -> (PhantomData<T>, usize) { (PhantomData, std::mem::size_of::<T>()) } my_size_of() }; size } ``` ``@rustbot`` label: F-inline_const
…laumeGomez Rollup of 10 pull requests Successful merges: - rust-lang#96557 (Allow inline consts to reference generic params) - rust-lang#96590 (rustdoc: when running a function-signature search, tweak the tab bar) - rust-lang#96650 (Collect function instance used in `global_asm!` sym operand) - rust-lang#96733 (turn `append_place_to_string` from recursion into iteration) - rust-lang#96748 (Fixes reexports in search) - rust-lang#96752 (Put the incompatible_closure_captures lint messages in alphabetical order) - rust-lang#96754 (rustdoc: ensure HTML/JS side implementors don't have dups) - rust-lang#96772 (Suggest fully qualified path with appropriate params) - rust-lang#96776 (Fix two minor issues in hir.rs) - rust-lang#96782 (a small `mirror_expr` cleanup) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
If I compile with "rustc --emit=metadata" it gives no compilation errors, this makes this improvement less useful than I expected. |
Permit `asm_const` and `asm_sym` to reference generic params Related rust-lang#96557 These constructs will be allowed: ```rust fn foofoo<const N: usize>() {} unsafe fn foo<const N: usize>() { asm!("/* {0} */", const N); asm!("/* {0} */", const N + 1); asm!("/* {0} */", sym foofoo::<N>); } fn barbar<T>() {} unsafe fn bar<T>() { asm!("/* {0} */", const std::mem::size_of::<T>()); asm!("/* {0} */", const std::mem::size_of::<(T, T)>()); asm!("/* {0} */", sym barbar::<T>); asm!("/* {0} */", sym barbar::<(T, T)>); } ``` `@Amanieu,` I didn't switch inline asms to use `DefKind::InlineAsm`, as I see little value doing that; given that no type inference is needed, it will only make typecking slower and more complex but will have no real gains. I did switch them to follow the same code path as inline asm during symbol resolution, though. The `error: unconstrained generic constant` you mentioned in rust-lang#76001 is due to the fact that `to_const` will actually add a wfness obligation to the constant, which we don't need for `asm_const`, so I have that removed. `@rustbot` label: +A-inline-assembly +F-asm
Allow inline consts to reference generic params Tracking issue: rust-lang#76001 The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo<T>() { let x = [4i32; std::mem::size_of::<T>()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::<T>() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::<T>() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do: ```rust fn assert_zst<T>() { struct F<T>(T); impl<T> F<T> { const V: () = assert!(std::mem::size_of::<T>() == 0); } let _ = F::<T>::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either: ```rust fn foo<T>() -> usize { let (_, size): (PhantomData<T>, usize) = const { const fn my_size_of<T>() -> (PhantomData<T>, usize) { (PhantomData, std::mem::size_of::<T>()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const
Pkgsrc changes: * adapt patches (libc crate version bump) * no longer pass -I/usr/pkg/include through via gcc-wrap script. Attempt at fixing version skew with curl package vs. internal version of curl. * new checksums Upstream changes: Version 1.62.0 (2022-06-30) ========================== Language -------- - [Stabilize `#[derive(Default)]` on enums with a `#[default]` variant][94457] - [Stop validating some checks in dead code after functions with uninhabited return types][93313] - [Fix constants not getting dropped if part of a diverging expression][94775] - [Support unit struct/enum variant in destructuring assignment][95380] - [Remove mutable_borrow_reservation_conflict lint and allow the code pattern][96268] Compiler -------- - [linker: Stop using whole-archive on dependencies of dylibs][96436] - [Make `unaligned_references` lint deny-by-default][95372] This lint is also a future compatibility lint, and is expected to eventually become a hard error. - [Only add codegen backend to dep info if -Zbinary-dep-depinfo is used][93969] - [Reject `#[thread_local]` attribute on non-static items][95006] - [Add tier 3 `aarch64-pc-windows-gnullvm` and `x86_64-pc-windows-gnullvm` targets\*][94872] - [Implement a lint to warn about unused macro rules][96150] - [Promote `x86_64-unknown-none` target to Tier 2\*][95705] \* Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Move `CStr` to libcore, and `CString` to liballoc][94079] - [Windows: Use a pipe relay for chaining pipes][95841] - [Replace Linux Mutex and Condvar with futex based ones.][95035] - [Replace RwLock by a futex based one on Linux][95801] - [std: directly use pthread in UNIX parker implementation][96393] Stabilized APIs --------------- - [`bool::then_some`] - [`f32::total_cmp`] - [`f64::total_cmp`] - [`Stdin::lines`] - [`windows::CommandExt::raw_arg`] - [`impl<T: Default> Default for AssertUnwindSafe<T>`] - [`From<Rc<str>> for Rc<[u8]>`][rc-u8-from-str] - [`From<Arc<str>> for Arc<[u8]>`][arc-u8-from-str] - [`FusedIterator for EncodeWide`] - [RDM intrinsics on aarch64][stdarch/1285] Clippy ------ - [Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions][94206] Cargo ----- - Added the `cargo add` command for adding dependencies to `Cargo.toml` from the command-line. [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-add.html) - Package ID specs now support `name@version` syntax in addition to the previous `name:version` to align with the behavior in `cargo add` and other tools. `cargo install` and `cargo yank` also now support this syntax so the version does not need to passed as a separate flag. - The `git` and `registry` directories in Cargo's home directory (usually `~/.cargo`) are now marked as cache directories so that they are not included in backups or content indexing (on Windows). - Added automatic `@` argfile support, which will use "response files" if the command-line to `rustc` exceeds the operating system's limit. Compatibility Notes ------------------- - `cargo test` now passes `--target` to `rustdoc` if the specified target is the same as the host target. [#10594](rust-lang/cargo#10594) - [rustdoc: Remove .woff font files][96279] - [Enforce Copy bounds for repeat elements while considering lifetimes][95819] Internal Changes ---------------- - [Unify ReentrantMutex implementations across all platforms][96042] These changes provide no direct user facing benefits, but represent significant improvements to the internals and overall performance of rustc and related tools. [93313]: rust-lang/rust#93313 [93969]: rust-lang/rust#93969 [94079]: rust-lang/rust#94079 [94206]: rust-lang/rust#94206 [94457]: rust-lang/rust#94457 [94775]: rust-lang/rust#94775 [94872]: rust-lang/rust#94872 [95006]: rust-lang/rust#95006 [95035]: rust-lang/rust#95035 [95372]: rust-lang/rust#95372 [95380]: rust-lang/rust#95380 [95431]: rust-lang/rust#95431 [95705]: rust-lang/rust#95705 [95801]: rust-lang/rust#95801 [95819]: rust-lang/rust#95819 [95841]: rust-lang/rust#95841 [96042]: rust-lang/rust#96042 [96150]: rust-lang/rust#96150 [96268]: rust-lang/rust#96268 [96279]: rust-lang/rust#96279 [96393]: rust-lang/rust#96393 [96436]: rust-lang/rust#96436 [96557]: rust-lang/rust#96557 [`bool::then_some`]: https://doc.rust-lang.org/stable/std/primitive.bool.html#method.then_some [`f32::total_cmp`]: https://doc.rust-lang.org/stable/std/primitive.f32.html#method.total_cmp [`f64::total_cmp`]: https://doc.rust-lang.org/stable/std/primitive.f64.html#method.total_cmp [`Stdin::lines`]: https://doc.rust-lang.org/stable/std/io/struct.Stdin.html#method.lines [`impl<T: Default> Default for AssertUnwindSafe<T>`]: https://doc.rust-lang.org/stable/std/panic/struct.AssertUnwindSafe.html#impl-Default [rc-u8-from-str]: https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#impl-From%3CRc%3Cstr%3E%3E [arc-u8-from-str]: https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#impl-From%3CArc%3Cstr%3E%3E [stdarch/1285]: rust-lang/stdarch#1285 [`windows::CommandExt::raw_arg`]: https://doc.rust-lang.org/stable/std/os/windows/process/trait.CommandExt.html#tymethod.raw_arg [`FusedIterator for EncodeWide`]: https://doc.rust-lang.org/stable/std/os/windows/ffi/struct.EncodeWide.html#impl-FusedIterator
Pkgsrc changes: * Bump required GCC to 7 (same as LLVM) to avoid ABI issues Fixes native i386 and powerpc 8.x build w/pkgsrc LLVM 14 * Bump available bootstraps to 1.61.0. * Also unlimit stacksize * Sync patches over from wip/rust * Adjust line number in patches which had non-zero offsets. * no longer pass -I/usr/pkg/include through via gcc-wrap script when building natively. Attempt at fixing version skew with curl package vs. internal version of curl (may not work...) * The NetBSD bootstraps now use .xz compression. * Use mk/atomic64.mk. Still have conditional for libatomic-links. * Default to using the internal LLVM when cross-building. Upstream changes: Version 1.62.1 (2022-07-19) ========================== Rust 1.62.1 addresses a few recent regressions in the compiler and standard library, and also mitigates a CPU vulnerability on Intel SGX. * [The compiler fixed unsound function coercions involving `impl Trait` return types.][98608] * [The compiler fixed an incremental compilation bug with `async fn` lifetimes.][98890] * [Windows added a fallback for overlapped I/O in synchronous reads and writes.][98950] * [The `x86_64-fortanix-unknown-sgx` target added a mitigation for the MMIO stale data vulnerability][98126], advisory [INTEL-SA-00615]. [98608]: rust-lang/rust#98608 [98890]: rust-lang/rust#98890 [98950]: rust-lang/rust#98950 [98126]: rust-lang/rust#98126 [INTEL-SA-00615]: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00615.html Version 1.62.0 (2022-06-30) ========================== Language -------- - [Stabilize `#[derive(Default)]` on enums with a `#[default]` variant][94457] - [Stop validating some checks in dead code after functions with uninhabited return types][93313] - [Fix constants not getting dropped if part of a diverging expression][94775] - [Support unit struct/enum variant in destructuring assignment][95380] - [Remove mutable_borrow_reservation_conflict lint and allow the code pattern][96268] Compiler -------- - [linker: Stop using whole-archive on dependencies of dylibs][96436] - [Make `unaligned_references` lint deny-by-default][95372] This lint is also a future compatibility lint, and is expected to eventually become a hard error. - [Only add codegen backend to dep info if -Zbinary-dep-depinfo is used][93969] - [Reject `#[thread_local]` attribute on non-static items][95006] - [Add tier 3 `aarch64-pc-windows-gnullvm` and `x86_64-pc-windows-gnullvm` targets\*][94872] - [Implement a lint to warn about unused macro rules][96150] - [Promote `x86_64-unknown-none` target to Tier 2\*][95705] \* Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Move `CStr` to libcore, and `CString` to liballoc][94079] - [Windows: Use a pipe relay for chaining pipes][95841] - [Replace Linux Mutex and Condvar with futex based ones.][95035] - [Replace RwLock by a futex based one on Linux][95801] - [std: directly use pthread in UNIX parker implementation][96393] Stabilized APIs --------------- - [`bool::then_some`] - [`f32::total_cmp`] - [`f64::total_cmp`] - [`Stdin::lines`] - [`windows::CommandExt::raw_arg`] - [`impl<T: Default> Default for AssertUnwindSafe<T>`] - [`From<Rc<str>> for Rc<[u8]>`][rc-u8-from-str] - [`From<Arc<str>> for Arc<[u8]>`][arc-u8-from-str] - [`FusedIterator for EncodeWide`] - [RDM intrinsics on aarch64][stdarch/1285] Clippy ------ - [Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions][94206] Cargo ----- - Added the `cargo add` command for adding dependencies to `Cargo.toml` from the command-line. [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-add.html) - Package ID specs now support `name@version` syntax in addition to the previous `name:version` to align with the behavior in `cargo add` and other tools. `cargo install` and `cargo yank` also now support this syntax so the version does not need to passed as a separate flag. - The `git` and `registry` directories in Cargo's home directory (usually `~/.cargo`) are now marked as cache directories so that they are not included in backups or content indexing (on Windows). - Added automatic `@` argfile support, which will use "response files" if the command-line to `rustc` exceeds the operating system's limit. Compatibility Notes ------------------- - `cargo test` now passes `--target` to `rustdoc` if the specified target is the same as the host target. [#10594](rust-lang/cargo#10594) - [rustdoc: Remove .woff font files][96279] - [Enforce Copy bounds for repeat elements while considering lifetimes][95819] Internal Changes ---------------- - [Unify ReentrantMutex implementations across all platforms][96042] These changes provide no direct user facing benefits, but represent significant improvements to the internals and overall performance of rustc and related tools. [93313]: rust-lang/rust#93313 [93969]: rust-lang/rust#93969 [94079]: rust-lang/rust#94079 [94206]: rust-lang/rust#94206 [94457]: rust-lang/rust#94457 [94775]: rust-lang/rust#94775 [94872]: rust-lang/rust#94872 [95006]: rust-lang/rust#95006 [95035]: rust-lang/rust#95035 [95372]: rust-lang/rust#95372 [95380]: rust-lang/rust#95380 [95431]: rust-lang/rust#95431 [95705]: rust-lang/rust#95705 [95801]: rust-lang/rust#95801 [95819]: rust-lang/rust#95819 [95841]: rust-lang/rust#95841 [96042]: rust-lang/rust#96042 [96150]: rust-lang/rust#96150 [96268]: rust-lang/rust#96268 [96279]: rust-lang/rust#96279 [96393]: rust-lang/rust#96393 [96436]: rust-lang/rust#96436 [96557]: rust-lang/rust#96557 [`bool::then_some`]: https://doc.rust-lang.org/stable/std/primitive.bool.html#method.then_some [`f32::total_cmp`]: https://doc.rust-lang.org/stable/std/primitive.f32.html#method.total_cmp [`f64::total_cmp`]: https://doc.rust-lang.org/stable/std/primitive.f64.html#method.total_cmp [`Stdin::lines`]: https://doc.rust-lang.org/stable/std/io/struct.Stdin.html#method.lines [`impl<T: Default> Default for AssertUnwindSafe<T>`]: https://doc.rust-lang.org/stable/std/panic/struct.AssertUnwindSafe.html#impl-Default [rc-u8-from-str]: https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#impl-From%3CRc%3Cstr%3E%3E [arc-u8-from-str]: https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#impl-From%3CArc%3Cstr%3E%3E [stdarch/1285]: rust-lang/stdarch#1285 [`windows::CommandExt::raw_arg`]: https://doc.rust-lang.org/stable/std/os/windows/process/trait.CommandExt.html#tymethod.raw_arg [`FusedIterator for EncodeWide`]: https://doc.rust-lang.org/stable/std/os/windows/ffi/struct.EncodeWide.html#impl-FusedIterator Version 1.61.0 (2022-05-19) ========================== Language -------- - [`const fn` signatures can now include generic trait bounds][93827] - [`const fn` signatures can now use `impl Trait` in argument and return position][93827] - [Function pointers can now be created, cast, and passed around in a `const fn`][93827] - [Recursive calls can now set the value of a function's opaque `impl Trait` return type][94081] Compiler -------- - [Linking modifier syntax in `#[link]` attributes and on the command line, as well as the `whole-archive` modifier specifically, are now supported][93901] - [The `char` type is now described as UTF-32 in debuginfo][89887] - The [`#[target_feature]`][target_feature] attribute [can now be used with aarch64 features][90621] - X86 [`#[target_feature = "adx"]` is now stable][93745] Libraries --------- - [`ManuallyDrop<T>` is now documented to have the same layout as `T`][88375] - [`#[ignore = "#"]` messages are printed when running tests][92714] - [Consistently show absent stdio handles on Windows as NULL handles][93263] - [Make `std::io::stdio::lock()` return `'static` handles.][93965] Previously, the creation of locked handles to stdin/stdout/stderr would borrow the handles being locked, which prevented writing `let out = std::io::stdout().lock();` because `out` would outlive the return value of `stdout()`. Such code now works, eliminating a common pitfall that affected many Rust users. - [`Vec::from_raw_parts` is now less restrictive about its inputs][95016] - [`std::thread::available_parallelism` now takes cgroup quotas into account.][92697] Since `available_parallelism` is often used to create a thread pool for parallel computation, which may be CPU-bound for performance, `available_parallelism` will return a value consistent with the ability to use that many threads continuously, if possible. For instance, in a container with 8 virtual CPUs but quotas only allowing for 50% usage, `available_parallelism` will return 4. Stabilized APIs --------------- - [`Pin::static_mut`] - [`Pin::static_ref`] - [`Vec::retain_mut`] - [`VecDeque::retain_mut`] - [`Write` for `Cursor<[u8; N]>`][cursor-write-array] - [`std::os::unix::net::SocketAddr::from_pathname`] - [`std::process::ExitCode`] and [`std::process::Termination`]. The stabilization of these two API s now makes it possible for programs to return errors from `main` with custom exit codes. - [`std::thread::JoinHandle::is_finished`] These APIs are now usable in const contexts: - [`<*const T>::offset` and `<*mut T>::offset`][ptr-offset] - [`<*const T>::wrapping_offset` and `<*mut T>::wrapping_offset`] [ptr-wrapping_offset] - [`<*const T>::add` and `<*mut T>::add`][ptr-add] - [`<*const T>::sub` and `<*mut T>::sub`][ptr-sub] - [`<*const T>::wrapping_add` and `<*mut T>::wrapping_add`][ptr-wrapping_add] - [`<*const T>::wrapping_sub` and `<*mut T>::wrapping_sub`][ptr-wrapping_sub] - [`<[T]>::as_mut_ptr`][slice-as_mut_ptr] - [`<[T]>::as_ptr_range`][slice-as_ptr_range] - [`<[T]>::as_mut_ptr_range`][slice-as_mut_ptr_range] Cargo ----- No feature changes, but see compatibility notes. Compatibility Notes ------------------- - Previously native static libraries were linked as `whole-archive` in some cases, but now rustc tries not to use `whole-archive` unless explicitly requested. This [change][93901] may result in linking errors in some cases. To fix such errors, native libraries linked from the command line, build scripts, or [`#[link]` attributes][link-attr] need to - (more common) either be reordered to respect dependencies between them (if `a` depends on `b` then `a` should go first and `b` second) - (less common) or be updated to use the [`+whole-archive`] modifier. - [Catching a second unwind from FFI code while cleaning up from a Rust panic now causes the process to abort][92911] - [Proc macros no longer see `ident` matchers wrapped in groups][92472] - [The number of `#` in `r#` raw string literals is now required to be less than 256][95251] - [When checking that a dyn type satisfies a trait bound, supertrait bounds are now enforced][92285] - [`cargo vendor` now only accepts one value for each `--sync` flag] [cargo/10448] - [`cfg` predicates in `all()` and `any()` are always evaluated to detect errors, instead of short-circuiting.][94295] The compatibility considerations here arise in nightly-only code that used the short-circuiting behavior of `all` to write something like `cfg(all(feature = "nightly", syntax-requiring-nightly))`, which will now fail to compile. Instead, use either `cfg_attr(feature = "nightly", ...)` or nested uses of `cfg`. - [bootstrap: static-libstdcpp is now enabled by default, and can now be disabled when llvm-tools is enabled][94832] Internal Changes ---------------- These changes provide no direct user facing benefits, but represent significant improvements to the internals and overall performance of rustc and related tools. - [debuginfo: Refactor debuginfo generation for types][94261] - [Remove the everybody loops pass][93913] [88375]: rust-lang/rust#88375 [89887]: rust-lang/rust#89887 [90621]: rust-lang/rust#90621 [92285]: rust-lang/rust#92285 [92472]: rust-lang/rust#92472 [92697]: rust-lang/rust#92697 [92714]: rust-lang/rust#92714 [92911]: rust-lang/rust#92911 [93263]: rust-lang/rust#93263 [93745]: rust-lang/rust#93745 [93827]: rust-lang/rust#93827 [93901]: rust-lang/rust#93901 [93913]: rust-lang/rust#93913 [93965]: rust-lang/rust#93965 [94081]: rust-lang/rust#94081 [94261]: rust-lang/rust#94261 [94295]: rust-lang/rust#94295 [94832]: rust-lang/rust#94832 [95016]: rust-lang/rust#95016 [95251]: rust-lang/rust#95251 [`+whole-archive`]: https://doc.rust-lang.org/stable/rustc/command-line-arguments.html#linking-modifiers-whole-archive [`Pin::static_mut`]: https://doc.rust-lang.org/stable/std/pin/struct.Pin.html#method.static_mut [`Pin::static_ref`]: https://doc.rust-lang.org/stable/std/pin/struct.Pin.html#method.static_ref [`Vec::retain_mut`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.retain_mut [`VecDeque::retain_mut`]: https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.retain_mut [`std::os::unix::net::SocketAddr::from_pathname`]: https://doc.rust-lang.org/stable/std/os/unix/net/struct.SocketAddr.html#method.from_pathname [`std::process::ExitCode`]: https://doc.rust-lang.org/stable/std/process/struct.ExitCode.html [`std::process::Termination`]: https://doc.rust-lang.org/stable/std/process/trait.Termination.html [`std::thread::JoinHandle::is_finished`]: https://doc.rust-lang.org/stable/std/thread/struct.JoinHandle.html#method.is_finished [cargo/10448]: rust-lang/cargo#10448 [cursor-write-array]: https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#impl-Write-4 [link-attr]: https://doc.rust-lang.org/stable/reference/items/external-blocks.html#the-link-attribute [ptr-add]: https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.add [ptr-offset]: https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.offset [ptr-sub]: https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.sub [ptr-wrapping_add]: https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.wrapping_add [ptr-wrapping_offset]: https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.wrapping_offset [ptr-wrapping_sub]: https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.wrapping_sub [slice-as_mut_ptr]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_mut_ptr [slice-as_mut_ptr_range]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_mut_ptr_range [slice-as_ptr_range]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_ptr_range [target_feature]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-target_feature-attribute
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Tracking issue: #76001
The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well.
However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have:
This would make inline consts super useful for compile-time checks and assertions:
This would create an error during monomorphization when
assert_zst
is instantiated with non-ZSTT
s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do:It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either:
@rustbot label: F-inline_const