Add `Box::clone_from_ref` and similar under `feature(clone_from_ref)`
Tracking issue: https://github.com/rust-lang/rust/issues/149075
Accepted ACP: https://github.com/rust-lang/libs-team/issues/483
This PR implements `clone_from_ref` (and `try_*` and `_*in` variants), to get a `Box<T>`, `Arc<T>`, or `Rc<T>` by cloning from a `&T` where `T: CloneToUninit`.
The "Implement..." commits replace some ad-hoc conversions with `clone_from_ref` variants, which can be split out to a separate PR if desired.
This PR will conflict with https://github.com/rust-lang/rust/pull/148769 due to usage of `Layout::dangling` (which that PR is renaming to `dangling_ptr`), so they should not be rolled up together, and the one which merges later will need to be amended.
Deny const auto traits
closerust-lang/rust#149285
The AST validation now detects and rejects const auto traits. Additionally, I updated an existing test that was using `const unsafe auto trait`.
r? fmease
[rustdoc] misc search index cleanups
Bunch of misc cleanups to search index generation (on the rustdoc side). Perf isn't improved unfortunately, but I do think most of these changes are improvements to readability/style.
Probably easier to review commit by commit.
Mangle symbols with a mangled name close to PDB limits with v0 instead of legacy mangling to avoid linker errors
This is rust-lang/compiler-team#934
As PDB debuginfo has a 64KiB limit for symbol names, we use v0 mangling instead of legacy mangling for symbol names >= 65000 bytes if PDB is used. The cutoff number was chosen to leave some room for potential errors in the empirical measurement of the limit of 65521 bytes, as well as potential symbol prefixes and suffixes that are applied later, plus some generous extra space.
Tracking issue: rust-lang/rust#148429
Fix some issues around `rustc_public`
cc rust-lang/rust#148266 .
follow-up of rust-lang/rust#148341 .
This fixes the issues that can be reproduced by `x test compiler/rustc_public`:
```
error: function `run` is never used
--> compiler/rustc_public/src/compiler_interface.rs:838:15
|
838 | pub(crate) fn run<'tcx, F, T>(interface: &CompilerInterface<'tcx>, f: F) -> Result<T, Error>
| ^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
error: unreachable `pub` item
--> compiler/rustc_public/src/unstable/mod.rs:25:1
|
25 | pub trait InternalCx<'tcx>: Copy + Clone {
| ---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
= note: `-D unreachable-pub` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unreachable_pub)]`
error: unreachable `pub` item
--> compiler/rustc_public/src/unstable/mod.rs:62:1
|
62 | pub trait Stable<'tcx>: PointeeSized {
| ---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
error: unreachable `pub` item
--> compiler/rustc_public/src/unstable/mod.rs:81:1
|
81 | pub trait RustcInternal {
| ---^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
error: could not compile `rustc_public` (lib) due to 4 previous errors
```
Update cargo submodule
7 commits in 9fa462fe3a81e07e0bfdcc75c29d312c55113ebb..2a7c4960677971f88458b0f8b461a866836dff59
2025-11-21 20:49:51 +0000 to 2025-11-25 19:58:07 +0000
- docs(config-include): prepare for doc stabilization (rust-lang/cargo#16301)
- fix(config-include): remove support of single string shorthand (rust-lang/cargo#16298)
- Revert "feat: Do not lock the artifact-dir for check builds" (rust-lang/cargo#16299)
- clean: Add --workspace support (rust-lang/cargo#16263)
- feat(tree): Add more native completions (rust-lang/cargo#16296)
- fix(package): exclude target/package from backups (rust-lang/cargo#16272)
- test: re-enable test since not flaky anymore (rust-lang/cargo#16287)
Simplify OnceCell Clone impl
Noticed when developing https://github.com/fast/mea/pull/79.
This may also apply to `OnceLock`. But unfortunately, we can't construct a completed `Once` beforehand.
Note that `OnceCell::from` is marked as [`rustc_const_unstable`](https://github.com/rust-lang/rust/issues/143773) so we don't need an extra `const fn from_value` to leverage possible const convert benefit.
Fix comment wording in simplify_comparison_integral.rs
This change corrects the wording in a comment within `simplify_comparison_integral.rs`, changing "user" to "used" to accurately describe that a moved value cannot be used later on.
The adjustment improves code documentation clarity while maintaining consistency with our standards for precise terminology in comments.
Fix invalid link generation for type alias methods
Fixes https://github.com/rust-lang/rust/issues/149205.
That one was quite the wild ride. First commit is the actual fix, the second commit is just a small name variable improvement while I was going through the code. Anyway, let's go through it:
* We don't generate directly implementations in the HTML files for local impls (which I think is a mistake and should be changed, gonna do that as a follow-up) but instead generate a JS file for each type alias containing the HTML for these impls.
* So in `write_shared.rs::TypeAliasPart::get`, when generating the JS file, we generate the impl into a `String` by calling `render_impl`. This method expects an `AssocItemLink` to help it generate the correct link to the item (I'm planning to also remove this enum because it's yet another way to generate anchors/hrefs).
* Problem was: we call the `provided_trait_methods` method on the impl item... which is empty if not a trait impl. This becomes an issue when we arrive in `render::assoc_href_attr` because of this code:
```rust
AssocItemLink::GotoSource(did, provided_methods) => {
let item_type = match item_type {
ItemType::Method | ItemType::TyMethod => {
if provided_methods.contains(&name) {
ItemType::Method
} else {
ItemType::TyMethod
}
}
item_type => item_type,
};
// ...
}
```
Since `provided_methods` is always empty, it means all methods on type aliases will be `TyMethod`, generating `#tymethod.` URLs instead of `#method.`.
* So generating `AssocItemLink::GoToSource` only on traits (when `provided_trait_methods` is supposed to return something) was the fix.
* And finally, because it's (currently) generating implementations only through JS, it means we cannot test it in `tests/rustdoc` so I had to write the test in `tests/rustdoc-gui`. Once I change how we generate local implementations for type aliases, I'll move it to `tests/rustdoc`.
r? ```@lolbinarycat```
add implementation-internal namespace for globalasm
Fixesrust-lang/rust#138261
Adds a namespace for `global_asm` with a lowercase letter which [is reserved for implementation-internal disambiguation](https://doc.rust-lang.org/rustc/symbol-mangling/v0.html#namespace:~:text=Lowercase%20letters%20are%20reserved%20for%20implementation%2Dinternal%20disambiguation%20categories%20(and%20demanglers%20should%20never%20show%20them)):
> Lowercase letters are reserved for implementation-internal disambiguation categories (and demanglers should never show them)
As a implementation-internal disambiguation category, the demangler implementations shouldn't need updated (i.e. if this were an uppercase letter, then our mangle-then-demangle checks would fail because the demangler would expect to have explicit handling). `'a'` is chosen arbitrarily, for **a**sm, but I can change it to something else if preferred.
`#[rustc_symbol_name]` only looks at top-level items, and would need a bunch of changes to be able to check the symbol for `foo::{constant}::{closure}` in the `global_asm` in this test, so for now the test just checks this compiles.
The alternative to this would be to prohibit declaration of items in the operand of a `global_asm`, which is a breaking change.
Stabilize `asm_cfg`
tracking issue: https://github.com/rust-lang/rust/issues/140364
closes https://github.com/rust-lang/rust/issues/140364
Reference PR:
- https://github.com/rust-lang/reference/pull/2063
# Request for Stabilization
## Summary
The `cfg_asm` feature allows `#[cfg(...)]` and `#[cfg_attr(...)]` on the arguments of the assembly macros, for instance:
```rust
asm!( // or global_asm! or naked_asm!
"nop",
#[cfg(target_feature = "sse2")]
"nop",
// ...
#[cfg(target_feature = "sse2")]
a = const 123, // only used on sse2
);
```
## Semantics
Templates, operands, `options` and `clobber_abi` in the assembly macros (`asm!`, `naked_asm!` and `global_asm!`) can be annotated with `#[cfg(...)]` and `#[cfg_attr(...)]`. When the condition evaluates to true, the annotated argument has no effect, and is completely ignored when expanding the assembly macro.
## Documentation
reference PR: https://github.com/rust-lang/reference/pull/2063
## Tests
- [tests/ui/asm/cfg.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks that `cfg`'d arguments where the condition evaluates to false have no effect
- [tests/ui/asm/cfg-parse-error.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks the parsing rules (parsing effectively assumes that the cfg conditions are all true)
## History
- https://github.com/rust-lang/rust/issues/140279
- https://github.com/rust-lang/rust/pull/140367
# Resolved questions
**how are other attributes handled**
Other attributes are parsed, but explicitly rejected.
# unresolved questions
**operand before template**
The current implementation expects at least one template string before any operands. In the example below, if the `cfg` condition evaluates to true, the assembly block is ill-formed. But even when it evaluates to `false` this block is rejected, because the parser still expects just a template (a template is parsed as an expression and then validated to ensure that it is or expands to a string literal).
Changing how this works is difficult.
```rust
// This is rejected because `a = out(reg) x` does not parse as an expresion.
asm!(
#[cfg(false)]
a = out(reg) x, //~ ERROR expected token: `,`
"",
);
```
**lint on positional arguments?**
Adding a lint to warn on the definition or use of positional arguments being `cfg`'d out was discussed in https://github.com/rust-lang/rust/issues/140279#issuecomment-2832237372 and subsequent comments. Such a lint is not currently implemented, but that may not be a blocker based on the comments there.
r? `@traviscross` (I'm assuming you'll reassign as needed)
The rustc-josh-sync Cronjob Bot