Port `#[cfg]` and `#[cfg_attr]` trace attributes to the new attribute parsers
This PR converts `cfg` and `cfg_trace` attributes to the new parsed representation.
The primary challenge is that re-parsing these attributes in the HIR is a performance regression, since these attributes were only used in rustdoc and clippy parsing them in the HIR is extra work that was not done in the compiler before. To solve this, we only parse the attributes once and then store their parsed representation in the AST.
resolve: Rename "name bindings" to "name declarations"
This was discussed previously in some name resolution specification threads on zulip.
Link: [#t-compiler/help > understanding early name resolution of imports @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/understanding.20early.20name.20resolution.20of.20imports/near/545306658)
The main change is that `NameBinding` is renamed to `Decl`.
The `Name` part is skipped because almost everything in `rustc_resolve` is about names.
So in general the naming looks more compact now (`binding: NameBinding` -> `decl: Decl`).
I didn't rename *everything* including all the local variables, but did rename most of significant interfaces.
Late resolution in particular uses "bindings" in slightly different meanings, I didn't touch that.
Also, some interface comments are added/improved.
Renaming list:
- fn `define_binding_local` -> `plant_decl_into_local_module`
- fn `add_macro_use_binding` -> `add_macro_use_decl`
- fn `binding_description` -> `decl_description`
- enum `PendingBinding` -> `PendingDecl`
- field `ImportKind::Single::bindings` -> `ImportKind::Single::decls`
- field `NameResolution::non_glob_binding` -> `NameResolution::non_glob_decl`
- field `NameResolution::glob_binding` -> `NameResolution::glob_decl`
- fn `best_binding` -> `best_decl`
- fn `import` -> `new_import_decl`
- fn `try_define_local` -> `try_plant_decl_into_local_module`
- fn `new_ambiguity_binding` -> `new_decl_with_ambiguity`
- fn `new_warn_ambiguity_binding` -> `new_decl_with_warn_ambiguity`
- field `UnnecessaryQualification::binding` -> `UnnecessaryQualification::decl`
- struct `MacroRulesBinding` -> `MacroRulesDef`
- field `MacroRulesBinding::binding` -> `MacroRulesDef::decl`
- variant `MacroRulesScope::Binding` -> `MacroRulesScope::Def`
- enum `LexicalScopeBinding` -> `LateDecl`
- variant `LexicalScopeBinding::Item` -> `LateDecl::Decl`
- variant `LexicalScopeBinding::Res` -> `LateDecl::RibDef`
- field `ModuleData::self_binding` -> `ModuleData::self_decl`
- struct `NameBindingData` -> `DeclData`
- type `NameBinding` -> `Decl`
- enum `NameBindingKind` -> `DeclKind`
- variant `NameBindingKind::Res` -> `DeclKind::Def`
- field `NameBindingKind::Import::binding` -> `DeclKind::Import::source_decl`
- field `PrivacyError::binding` -> `PrivacyError::decl`
- field `ExternPreludeEntry::item_binding` -> `ExternPreludeEntry::item_decl`
- field `ExternPreludeEntry::flag_binding` -> `ExternPreludeEntry::flag_decl`
- field `Resolver::binding_parent_modules` -> `Resolver::decl_parent_modules`
- field `Resolver::dummy_binding` -> `Resolver::dummy_decl`
- field `Resolver::builtin_types_bindings` -> `Resolver::builtin_type_decls`
- field `Resolver::builtin_attrs_bindings` -> `Resolver::builtin_attr_decls`
- field `Resolver::registered_tool_bindings` -> `Resolver::registered_tool_decls`
- fn `ResolverArenas::new_res_binding` -> `ResolverArenas::new_def_decl`
- fn `ResolverArenas::new_pub_res_binding` -> `ResolverArenas::new_pub_def_decl`
- fn `ResolverArenas::alloc_name_binding` -> `ResolverArenas::alloc_decl`
- fn `ResolverArenas::alloc_macro_rules_binding` -> `ResolverArenas::alloc_macro_rules_def`
- fn `set_binding_parent_module` -> `set_decl_parent_module`
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
THIR pattern building: Move all `thir::Pat` creation into `rustc_mir_build::thir::pattern`
The code in `thir::cx::block` was the only code outside of `thir::pattern` that created `thir::Pat` nodes.
Moving it makes the signature of `pat_from_hir` a bit messier, but ensures that all `thir::Pat` creation occurs in one module. That will be useful when trying to change `thir::Pat`, e.g. by adding fields to remove the need for wrapper nodes.
There should be no change to compiler output.
use PIDFD_GET_INFO ioctl when available
This way using pidfd_spawnp won't have to rely on procfs, avoiding an unpleasant edge-case where the child is spawned but we can't get the pid. And pidfd.{try_}wait will be able to return the exit status even after a process has been reaped. At least on newer kernels.
Tracking issue: https://github.com/rust-lang/rust/issues/82971
Refactor function names of `rustc_ast_lowering`
close: rust-lang/rust#150062
I'll rebase after https://github.com/rust-lang/rust/pull/149114 is merged.
Would it be better to change `lower_const_path_to_const_arg` → `lower_const_path_to_const_arg_and_intern`,
`lower_array_length_to_const_arg` → `lower_array_length_to_const_arg_and_intern`?
r? ``@lcnr``
rustc_codegen_llvm: update alignment for double on AIX
This was recently fixed upstream in LLVM, so we update our default layout to match.
````@rustbot```` label: +llvm-main
`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`
This way using pidfd_spawnp won't have to rely on procfs, avoiding an unpleasant edge-case
where the child is spawned but we can't get the pid.
And `pidfd.{try_}wait` will be able to return the exit status even after a process has been reaped.
At least on newer kernels.
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`)
