Fix macro_metavar_expr_concat behavior with nested repetitions
**The Bug**: The `${concat(...)}` expression was using the wrong loop index when inside nested repetitions (like optional groups), causing it to get "stuck" on the first element and generate duplicate code.
**The Fix**: Updated `metavar_expr_concat` in `transcribe.rs` to correctly search the repetition stack (`tscx.repeats`) for the target variable instead of blindly using the last index.
**Tests**:
Added `tests/ui/macros/concat-nested-repetition.rs.`
Fixesrust-lang/rust#150002
Fix ICE when transmute Assume field is invalid
This PR fixes an internal compiler error in `rustc_transmute` where initializing an `Assume` field (like `alignment`) with a non-scalar constant (like a struct) caused a panic.
The fix updates `from_const` to use `try_to_scalar()` instead of assuming the value is always a leaf. It now gracefully returns `None` for invalid types, allowing the compiler to report standard "missing field initialiser" errors instead of crashing.
Fixesrust-lang/rust#150506
MGCA: pretty printing for struct expressions and tuple calls
not sure
1. if there any tests that i need to adjust
2. if i should add any test for it
3. if humanity has come up with anything better than checking if that's first iteration or not with flag when printing sequences with separator
in case there is no tests for it and i dont have to add any, there is a demonstration of this ✨ pretty ✨ printing (this is output from `-Z unpretty=hir`)
```
fn test_errors<const N:
usize>() {
// accepts_enum::<{ None::<u32> }>();
accepts_point::<Point1 { a: N, b: N }>();
accepts_point::<Point(N, N)>();
}
```
btw it does not print const block
for this
```
accepts_point::<{ Point1 { a: const {N + 1}, b: N } }>();
```
it will print
```
accepts_point::<Point1 { a: { N + 1 }, b: N }>();
```
not sure if we want to print const blocks or not
r? BoxyUwU
`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`
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
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
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~~
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
Add missing translator resources for interface parse_cfg and parse_check_cfg
Missing resources leads to the failure of `translate_message`.
Fixesrust-lang/rust#150654
Forbid generic parameters in types of #[type_const] items
fixesrust-lang/rust#150614
we enforce the same restriction on `#[type_const]` const items that already exists for const generic parameters - when `generic_const_parameter_types` feature gate is not enabled, the type of a `#[type_const]` item cannot reference generic parameters. implementation follows the same pattern used for const generic parameters. we check if the item has the `#[type_const]` attribute and if the feature gate is disabled, then we apply `RibKind::ConstParamTy` restrictions when visiting the type, which prevents the use of generic parameters.
check is added in three places:
- Free const items (`ItemKind::Const`)
- Trait associated consts (`AssocItemKind::Const` in traits)
- Impl associated consts (`AssocItemKind::Const` in impls)
added tests for new feature, hope i get this task right :>
r? `@BoxyUwU`
compiletest: Support revisions in debuginfo (read: debugger) tests
And start using revisions in `tests/debuginfo/macro-stepping.rs` to prevent regressing both with and without `SingleUseConsts` MIR pass.
I recommend commit-by-commit review.
## ~TODO~
- [x] Verify this more carefully.
- [x] Possibly do some preparatory PRs before taking this PR out of draft.
- [x] Rebase on https://github.com/rust-lang/rust/pull/150205 once merged so we don't have to add another "`+ 1`".
## CC
CC ``@Zalathar`` since you might have opinions about that I expose a helper function to reduce duplication
CC ``@saethlin`` since this is what we will use for `tests/debuginfo/basic-stepping.rs` in https://github.com/rust-lang/rust/pull/147426 (in the same way I use it in `tests/debuginfo/macro-stepping.rs` here)
Added codegen tests for different forms of `Option::or`
Adds tests to check the output of the different ways of writing `Option::or`
Fixesrust-lang/rust#124533
Removed confusing diagnostics note for trait required for `?` operator use
- **test: modified `bad-question-mark-on-trait-objects` to match expected behavior**
- **removed confusing message from diagnostics**
fixes [#150527](https://github.com/rust-lang/rust/issues/150527)
Detect cases where `?` is applied on a type that could be coming from a different crate version than expected
```
error[E0277]: `?` couldn't convert the error to `dependency::Error`
--> replaced
|
LL | fn main() -> Result<(), Error> {
| ----------------- expected `dependency::Error` because of this
...
LL | Err(Error2)?;
| -----------^ the trait `From<Error2>` is not implemented for `dependency::Error`
| |
| this can't be annotated with `?` because it has type `Result<_, Error2>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: the trait `From<Error2>` is not implemented for `dependency::Error`
but trait `From<()>` is implemented for it
--> replaced
|
LL | impl From<()> for Error {
| ^^^^^^^^^^^^^^^^^^^^^^^
= help: for that trait implementation, expected `()`, found `Error2`
= note: there are multiple different versions of crate `dependency` in the dependency graph
= help: you can use `cargo tree` to explore your dependency tree
```
The existing checks rely on having access to the actual types/traits that diverged to detect they are called the same, come from different crates with the same name. The new check is less specific, merely looking to see if the crate name the involved type belongs has multiple crates.
CC rust-lang/rust#78552.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#149991 (Add checks for gpu-kernel calling conv)
- rust-lang/rust#150047 (std: merge `sys::pal::common` and `sys_common` into `sys::helpers`)
- rust-lang/rust#150441 (do not suggest method call removal if it changes receiver type)
- rust-lang/rust#150616 (Update `browser-ui-test` version to `0.23.0`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add checks for gpu-kernel calling conv
The `gpu-kernel` calling convention has several restrictions that were not enforced by the compiler until now.
Add the following restrictions:
1. Cannot be async
2. Cannot be called
3. Cannot return values, return type must be `()` or `!`
4. Arguments should be simple, i.e. passed by value. More complicated types can work when you know what you are doing, but it is rather unintuitive, one needs to know ABI/compiler internals.
5. Export name should be unmangled, either through `no_mangle` or `export_name`. Kernels are searched by name on the CPU side, having a mangled name makes it hard to find and probably almost always unintentional.
Tracking issue: rust-lang/rust#135467
amdgpu target tracking issue: rust-lang/rust#135024
``@workingjubilee,`` these should be all the restrictions we talked about a year ago.
cc ``@RDambrosio016`` ``@kjetilkjeka`` for nvptx
tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: New test
Closesrust-lang/rust#60044 which has one 👍 and one ❤️ vote and just **E-needs-test**.
Make `asm_experimental_arch` work in `allow_internal_unstable` macros
This change makes it possible to use unstable `asm!`, usually requiring `feature(asm_experimental_arch)`, in proc-macros with the `allow_internal_unstable` attribute.
The test was added on a target where `asm!` is unstable: Wasm. However, this affects *any* target with an unstable `asm!` implementation.
