`Vec::push` in consts MVP
Example:
```rust
const X: &'static [u32] = {
let mut v = Vec::with_capacity(6);
let mut x = 1;
while x < 42 {
v.push(x);
x *= 2;
}
assert!(v.len() == 6);
v.const_make_global()
};
assert_eq!([1, 2, 4, 8, 16, 32], X);
```
Oh this is fun...
* We split out the implementation of `Global` such that it calls `intrinsics::const_allocate` and `intrinsics::const_deallocate` during compile time. This is achieved using `const_eval_select`
* This allows us to `impl const Allocator for Global`
* We then constify everything necessary for `Vec::with_capacity` and `Vec::push`.
* Added `Vec::const_make_global` to leak and intern the final value via `intrinsics::const_make_global`. If we see any pointer in the final value of a `const` that did not call `const_make_global`, we error as implemented in rust-lang/rust#143595.
r? `@rust-lang/wg-const-eval`
To-do for me:
* [x] Assess the rustdoc impact of additional bounds in the method
* [x] ~~Increase test coverage~~ I think this is enough for an unstable feature.
Merge `associated_const_equality` feature gate into MGCA
Tracking Issues: rust-lang/rust#132980rust-lang/rust#92827
Merge `associated_const_equality`(ACE) feature gate into `min_generic_const_args`(MGCA).
- Replaces `features().associated_const_equality()` checks with `features().min_generic_const_args()`
- Updates the parser to gate associated const equality under `min_generic_const_args`
- Moves `associated_const_equality` to the removed features list
- Removes the `associated_const_equality` method from the `Features` trait
- Updates all affected tests and tools (rust-analyzer, clippy)
Closesrust-lang/rust#150617
r? `@BoxyUwU`
Improve alloc `Vec::retain_mut` performance
Hi,
While reading the rustc source code, I noticed it uses `smallvec` and `thin-vec` in many places. I started reviewing those crates, optimized their `retain_mut` implementation, and then realized they were using the exact same algorithm as `alloc::vec::Vec` with less unsafe So now I’m back here with a PR for the standard library 😂.
In my benchmarks, this version is noticeably faster when `retain_mut` actually removes elements (thanks to fewer pointer operations, it just advances `write_index`), while performing identically to the current implementation when nothing is removed.
Let’s see if bors likes this change or not.
Tidying up tests/ui/issues 16 tests [7/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
r? Kivooeo
`oneshot` Channel
Tracking Issue: https://github.com/rust-lang/rust/issues/143674
This PR adds an experimental `oneshot` module.
Before talking about the API itself, I would prefer to get some of these questions below out of the way first. And as discussed in the [ACP](https://github.com/rust-lang/libs-team/issues/610) it would be
# Unresolved Questions
- [x] ~~Why exactly is it okay for `Sender` to be `Sync`? Or basically, how do we boil down the discussion in https://github.com/rust-lang/rust/pull/111087 into a comment for the `unsafe impl<T: Send> Sync for Sender<T> {}`?~~
- [x] ~~Why is `mpsc::Receiver` `!Sync` but `mpmc::Receiver` is `Sync`? Should `oneshot::Receiver` be `Sync` or not?~~
- [ ] Should this PR try to add an `is_ready` method as proposed in the tracking issue? If so, then the surface of this PR would likely need to increase to add a `pub(crate) fn is_disconnected` method to `mpmc` (might even be a good idea to add that to all 3 channel flavors).
- [ ] In a similar vein to the previous question, should the first internal implementation simply be a wrapper around `mpmc`, or should it be a wrapper around the internal crossbeam implementation?
- [ ] Should the `Sender` and `Receiver` operations be methods or associated methods? So `sender.send(msg)` or `Sender::send(sender, msg)`? The method syntax is more consistent with the rest of the ecosystem (namely `tokio`)
cleaned up cast-enum-const.rs
cleaned up ufcs-trait-object-format.rs
add comment to cast-to-box-arr.rs
add comment to shadow-primitives.rs
add comment to associated-type-const-nomalization.rs
add comment to fn-trait-explicit-call.rs
add comment to call-unit-struct-impl-fn-once.rs
add comment to cast-to-char-compare.rs
add comment to self-in-method-body-resolves.rs
add comment to derive-debug-newtype-unsized-slice.rs
add comment to tuple-ref-order-distinct-impls.rs
add comment to derive-debug-generic-with-lifetime.rs
add comment to recursive-trait-bound-on-type-param.rs
cleaned up const-static-ref-to-closure.rs
add comment to const-iter-no-conflict-for-loop.rs
std: sys: fs: uefi: Implement rename
- Using the file_name field in `EFI_FILE_INFO` works for renaming, even when changing directories.
- Does not work for cross-device rename, but that is already expected behaviour according to the docs:
"This will not work if the new name is on a different mount point."
- Also add some helper code for dealing with UefiBox<file::Info>.
- Tested using OVMF in qemu.
- edk2 implementation of the same: 66346d5ede/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c (L455)
``@rustbot`` label +O-UEFI
Update cell.rs, correct module level doc
This change corrects the Cell<T> section by replacing `&mut` with `&` so the statement reads "an &T to the inner value can never be obtained". It also emphasizes that a single &mut T to the inner value can be obtained (e.g. via method core::cell::Cell::get_mut).
This removes `associated_const_equality` as a separate feature gate and makes it part of `min_generic_const_args` (mgca).
Key changes:
- Remove `associated_const_equality` from unstable features, add to removed
- Update all test files to use `min_generic_const_args` instead
- Preserve the original "associated const equality is incomplete" error message by specially handling `sym::associated_const_equality` spans in `feature_gate.rs`
- Rename FIXME(associated_const_equality) to FIXME(mgca)
MGCA: Support for tuple constructors
r? BoxyUwU
part of https://github.com/rust-lang/rust/issues/132980fixesrust-lang/rust#136379fixesrust-lang/rust#138132
i tried to keep implementation very minimal and it's very similar to how structs was implemented with small adjustments
this does not make const constructor like None works, just something like Some(n)
todo:
* ~~tests~~
* write a better description (not sure if needed)
* add more comments and FIXMEs from structs code
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#149681 (resolve: Split `Scope::Module` into two scopes for non-glob and glob bindings )
- rust-lang/rust#150426 (Update offload test and verify that tgt_(un)register_lib have the right type)
- rust-lang/rust#150678 (relate.rs: tiny cleanup: eliminate temp vars)
r? `@ghost`
`@rustbot` modify labels: rollup
Update offload test and verify that tgt_(un)register_lib have the right type
Apparently, we weren't running offload tests when Enzyme wasn't built. Time to fix that.
Also adds a test mode which generates the host IR, but does not expect device IR/artifacts. This way, we don't have to handle artifacts and paths in our tests.
Also removes some outdated documentation.
cc `@Kevinsala,` `@Sa4dUs`
closes: https://github.com/rust-lang/rust/issues/150415
~~blocked on `needs-offload` infrastructure landing in https://github.com/rust-lang/rust/pull/150427~~
THIR pattern building: Pass HIR nodes instead of loose types/spans
This should make it easier to keep track of where the types/spans came from.
There should be no change to compiler output.
---
In the future I would also like to make more of these lowering methods return `Box<thir::Pat>` instead of `thir::PatKind`, so that it becomes feasible to add more fields to `thir::Pat` (e.g. for https://github.com/rust-lang/rust/pull/150498#discussion_r2652138926). That will be easier if those methods have easy access to the corresponding HIR pattern node, from which they can obtain a type and span.
alloc: Move Cow impl to existing ones
Right now, the `borrow.rs` module starts with a `Cow` impl, although most of them can be found below.
This hurts code readability because there is `ToOwned` alongside its impl directly below it.
Moving it to the others down below makes sense here, given that the entire enum depends on `ToOwned` anyways.
make specialization of `Vec::extend` and `VecDeque::extend_front` work for vec::IntoIter with any `Allocator`, not just `Global`
These functions consume all the elements from the respective collection, but do not care about the `Allocator` they use. Without specifying one (like in `vec::IntoIter<T>`) the specialization is only chosen when `A=Global`.
(extra context: `VecDeque::extend_front` is unstable and tracked by rust-lang/rust#146975)
test: add regression cases for valtree hashing ICE
This PR extends the existing regression test `printing_valtrees_supports_non_values.rs` to cover cases that previously caused an ICE in `const_kind.rs` due to hashing inference variables.
It specifically adds:
A case where an associated constant is used without the required trait bound.
The `0: _` case as suggested in [Here](https://github.com/rust-lang/rust/issues/150409#issuecomment-3700022690)
Fixesrust-lang/rust#150409
