As with `DIBuilderBox`, the "Box" suffix does a better job of communicating
that this is an owning pointer to some borrowable resource.
This also renames the `raw` method to `as_ref`, which is what it would have
been named originally if the `Deref` problem had been known at the time.
Async drop fix for async_drop_in_place<T> layout for unspecified T
Fix for https://github.com/rust-lang/rust/issues/140423.
Layout of `async_drop_in_place<T>::{closure}` is calculated for unspecified T from dataflow_const_prop `try_make_constant`.
`@oli-obk,` do you think, it may be a better solution to add check like `if !args[0].is_fully_specialized() { return None; }` in `fn async_drop_coroutine_layout`?
And could you, pls, recommend, how to implement `is_fully_specialized()` in a most simple way?
Add T-compiler backports Zulip notifications
This patch make it so, that the triagebot willl send notifications to the Zulip channel [#t-compiler/backports](https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports) when a label `{stable-beta}-nominated` is added to beta or stable backport pull request. Requirement to trigger this notification is that the pull request be labeled `T-compiler`.
Note: Zulip notifications can send notifications also on other events (`message_on_close` and `message_on_reopen`) but I omitted them for now, I am not yet sure we need them.
r? `@davidtwco`
Partially stabilize LoongArch target features
Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.
Specifically, this PR stabilizes the following target features:
* f
* d
* frecipe
* lasx
* lbt
* lsx
* lvz
Docs PR: https://github.com/rust-lang/reference/pull/1707
r? `@Amanieu`
This module comment describes why it's OK for LLVM bindings to declare a
parameter type of `*const c_uchar` for pointer/length strings, even though the
corresponding parameter on the C/C++ side uses `const char *`.
Adding a searchable term to each such parameter should make it easier for
future maintainers to understand why `*const c_uchar` is being used instead of
`*const c_char`.
Rollup of 7 pull requests
Successful merges:
- #140792 (Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations)
- #140795 (Prefer to suggest stable candidates rather than unstable ones)
- #140865 (Make t letter looks like lowercase rather than uppercase)
- #140878 (Two expand-related cleanups)
- #140882 (Split duration_constructors to get non-controversial constructors out)
- #140886 (Update deps of bootstrap for Cygwin)
- #140903 (test intrinsic fallback bodies with Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
test intrinsic fallback bodies with Miri
`@Urgau` noted in https://github.com/rust-lang/rust/pull/140792 that fallback bodies our backends don't use are untested... which is correct, and it is a problem. So this adds a testing-only flag to Miri to force the use of fallback bodies, and adds a run of the Miri test suite with that flag to CI. This should not take much more than a minute so I hope it's fine? Let's see how long it actually takes.
While at it, I made that test run also enable MIR optimizations. Miri's CI has a run with that, and it has caught mir-opt bugs in the past -- this way we'd see the CI failure earlier.
r? `@scottmcm`
Update deps of bootstrap for Cygwin
This PR just runs
```
cargo update fd-lock xattr libc errno
```
It reduces dependency on `rustix 0.38.40` and updates `libc` & `errno`. Now it compiles successfully on Cygwin:)
Prefer to suggest stable candidates rather than unstable ones
Fixes#140240
The logic is to replace unstable suggestions if we meet a new stable one, and do nothing if any other situation. In old logic, we just use the first candidate we meet as the suggestion for the same items.
E.g., `std::range::legacy::Range` vs `std::ops::Range`, `legacy` in the former is unstable, we prefer to suggest use the latter.
Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations
This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations.
This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them.
Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`.
r? `@tgross35`
try-job: aarch64-gnu
try-job: dist-various-1
try-job: dist-various-2
[^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations
This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations.
This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them.
Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`.
r? `@tgross35`
try-job: aarch64-gnu
try-job: dist-various-1
try-job: dist-various-2
[^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
The `mir_drops_elaborated_and_const_checked` query result has been
stolen already and cannot be borrowed again. Use the `optimized_mir`
query result instead.
changelog: [`missing_const_for_fn`]: fix ICE with some compilation
options
Fixesrust-lang/rust-clippy#14774
r? @Jarcho
The `mir_drops_elaborated_and_const_checked` query result has been
stolen already and cannot be borrowed again. Use the `optimized_mir`
query result instead.
1.87.0 release notes: remove nonsensical `~` operator
There is no `~` unary prefix operator, and it definitely shouldn't be in the release notes for a feature whose introducing PR doesn't test for it (because it doesn't exist). Also fix an unnecessary `}` on the same line.
r? ``@pietroalbini``
remove 'unordered' atomic intrinsics
As their doc comment already indicates, these operations do not currently have a place in our memory model. The intrinsics were introduced to support a hack in compiler-builtins, but that hack recently got removed (see https://github.com/rust-lang/compiler-builtins/issues/788).
remove 'unordered' atomic intrinsics
As their doc comment already indicates, these operations do not currently have a place in our memory model. The intrinsics were introduced to support a hack in compiler-builtins, but that hack recently got removed (see https://github.com/rust-lang/compiler-builtins/issues/788).
remove intrinsics::drop_in_place
This was only ever accidentally stable, and has been marked as deprecated since Rust 1.52, released almost 4 years ago. We've removed the old serialization `derive`s, maybe we can remove this one as well?
As suggested by ``@jhpratt,`` let's see what crater says for this one.
