Weak's type parameter may dangle on drop
Way back in 34076bc0c9, #\[may_dangle\] was added to Rc\<T\> and Arc\<T\>'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However, Weak was not covered by that test, and therefore no #\[may_dangle\] was forced to be added at the time.
As far as dropping, Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl, which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence, in which case better not drop the T. Or there are no strong references still in existence, in which case the T would already have been dropped previously by the drop of the last strong count.
deal with `const_evaluatable_checked` in `ConstEquate`
Failing to evaluate two constants which do not contain inference variables should not result in ambiguity.
Remove doubled braces in non_exhaustive structs’ documentation text.
In commit 4b80687854 (part of Rust 1.52.1) many calls to `write!(w,` were replaced with `w.write_str(`, but this one contained braces that were doubled to escape them when taken as a format string, and so changing the call without changing the text caused them to become doubled in the final HTML output.
I examined `print_item.rs` and the diff of that prior commit for any other occurrences of this mistake and I did not find any.
Better English for documenting when to use unimplemented!()
I don't think "plan of using" is correct here. I considered "plan on using" but eventually decided "plan to use" is better.
Use TargetTriple::from_path in rustdoc
This fixes the problem reported in https://github.com/Rust-for-Linux/linux/pull/272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.
Bump bootstrap compiler to beta 1.53.0
This PR bumps the bootstrap compiler to version 1.53.0 beta, as part of our usual release process (this was supposed to be Wednesday's step, but creating the beta release took longer than expected).
The PR also includes the "Bootstrap: skip rustdoc fingerprint for building docs" commit, see the reasoning [on Zulip](https://zulip-archive.rust-lang.org/241545trelease/88450153betabootstrap.html).
r? `@Mark-Simulacrum`
In commit 4b80687854 (part of Rust 1.52.1)
many calls to `write!(w,` were replaced with `w.write_str(`, but this
one contained braces that were doubled to escape them when taken as a
format string, and so changing the call without changing the text caused
them to become doubled in the final HTML output.
I examined `print_item.rs` and the diff of that prior commit for any
other occurrences of this mistake and I did not find any.
Make building THIR a stealable query
This PR creates a stealable `thir_body` query so that we can build the THIR only once for THIR unsafeck and MIR build.
Blocked on #83842.
r? `@nikomatsakis`
Replace more "NULL" with "null"
Error messages in THIR unsafeck still contain "NULL", make them lowercase to be consistent with MIR unsafeck (cc #84842).
Restore sans-serif font for module items.
This was broke in #84462 by modifying a style that applied both to
searches and to module items (and other tables).
Fixes#85616.
Fixes https://github.com/rust-lang/rust/issues/85545.
r? `@camelid`
Extend `rustc_on_implemented` to improve more `?` error messages
`_Self` could match the generic definition; this adds that functionality for matching the generic definition of type parameters too.
Your advice welcome on the wording of all these messages, and which things belong in the message/label/note.
r? `@estebank`
fix pad_integral example
pad_integral's parameter `is_nonnegative - whether the original integer was either positive or zero`, but in example it checked as `self.nb > 0`, so it previously printed `-0` for `format!("{}", Foo::new(0)`, what is wrong.
Update std::array module doc header
This line is very outdated; not only are traits implemented on arrays of arbitrary length, those implementations are documented on the primitive type, not in this module.
Extremely outdated; not only are traits implemented on arrays of arbitrary length, those implementations are documented on the primitive type, not in this module.
rustdoc: render `<Self as X>::Y` type casts properly
Rustdoc didn't render any `<Self as X>` casts which causes invalid code inside the documentation. This is fixed by this PR by checking if the target type `X` is different from `Self`, and if so, it will render a typecast.
Resolves#85454