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.
Relocate issues/issue-51154.rs to closures/box-generic-closure.rs
Relocate issues/issue-51515.rs to
borrowck/assignment-to-immutable-ref.rs
Relocate issues/issue-53348.rs to mismatched_types/deref-string-assign.rs
Relocate issues/issue-52717.rs to
pattern/match-enum-struct-variant-field-missing.rs
Relocate issues/issue-53300.rs to
type/cannot-find-wrapper-with-impl-trait.rs
Currently, If `expected_def_id` and `another_trait_def_id` have their
crate imported as ExternCrateSource::Path the method
get_extern_crate_renamed_symbol() will return None for both, resulting
in a false positive. This fixes the issue by using a slitly different
approach, we use a predicate instead and do the comparison of the item
names only when both crates are imported as ExternCrateSource::Extern and
are direct dependencies of the LOCAL_CRATE, otherwise false is returned.
If the calling function had more target features enabled than the
callee than the attribute wasn't being applied as the arguments for
the check had been swapped round. Also includes target features that
are part of the global set as the warning was checking those but when
adding the attribute they were not checked.
Add a codegen-llvm test to check that the attribute is actually
applied as previously only the warning was being checked.
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
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)
Make deref_nullptr deny by default instead of warn
This lint was added 4 years ago in https://github.com/rust-lang/rust/pull/83948 and I cannot find any discussion on that PR or its issue about whether it should be warn or deny by default.
I think keeping this lint to warn was at one point in the past justifiable because of the old bindgen behavior of generating tests that do null pointer derefs. I've certainly heard that argument. I don't think it holds up now, so I think we should be more firm about code that is definitely UB.
We merged https://github.com/rust-lang/rust/pull/134424 which adds a runtime check for null pointer reads/writes, with very little fanfare. So now we know things like: This lint warns on 111 crates in crater, but 106 crates are encountering the runtime UB check. 65 crates hit both the lint and a runtime check. Of the 46 crates that only hit the lint, 25 look to me like machine-generated bindings, and all hits except 3a0eff4bd1/src/main.rs (L454) are trying to compute a field offset, and should use `offset_of!`.
Based on the contents of the crater runs for 1.91, I'd expect these crates to go from test-fail to build-fail as a result of this change:
```
gh/bernardjason/rust-invaders
gh/Leinnan/doppler
gh/Max-E/rust-gl-python-gtk
gh/nslebruh/rust-opengl-glfw
gh/nslebruh/rust_physics_gl_test
gh/oraoto/php-stacktrace
gh/playXE/jsrs
gh/Plecra/asm-w-ownership
gh/TateKennington/ROpenGL
gh/WillFarris/voxel-game
reg/ochre
```
Most of the crates where the lint fires already don't build for other reasons (note there are a lot of C bindings wrapper crates in the set).
v0 mangling for std on nightly
Following rust-lang/rust#89917 and rust-lang/compiler-team#938, it doesn't make sense that `std` for these channels would have legacy mangling while the user's code would use `v0`.
r? `@Kobzol`
So that when we later add support for revisions we can use the same
syntax for revisions as elsewhere.
This also prevents people from making typos for commands since
`src/tools/compiletest/src/directives/directive_names.rs` will catch such
typos now.
Note that we one FIXME for a non-trivial change for later:
```
// FIXME(148097): Change `// cdb-checksimple_closure` to `//@ cdb-check:simple_closure`
```
Use `let...else` consistently in user-facing diagnostics
resolve: rust-lang/rust#148772
Standardize `let...else` terminology in user-facing diagnostics.
Goal: Consistently use `let...else` in all error/warning messages.
Internal technical names (`let-else`) in comments and documentation remain unchanged.
cc ``@carols10cents,`` ``@jieyouxu``
rustdoc: make mergeable crate info more usable
Part of https://github.com/rust-lang/rust/issues/130676
Adds documentation and a feature change aimed at making this usable without breaking backwards compat.
cc ``@EtomicBomb``
