[std] Add xcoff in object's feature list
object-0.32.0 has supported XCOFF format. And backtrace in submodule has been updated to support XCOFF and AIX. Add `xcoff` to supported feature list to make backtrace built on AIX.
Add ASCII whitespace trimming functions to `&str`
- Add `trim_ascii_start`, `trim_ascii_end`, and `trim_ascii` functions to `&str` for trimming ASCII whitespace
- Add `#[inline]` to `[u8]` `trim_ascii` functions
These functions are feature-gated by `#![feature(byte_slice_trim_ascii)]` #94035
Make `IMPLIED_BOUNDS_ENTAILMENT` into a hard error from a lint
closes#105572
Removes the `IMPLIED_BOUNDS_ENTAILMENT` and makes the `compare_method_predicate_entailment` logic just run once.
r? lcnr
Rollup of 5 pull requests
Successful merges:
- #118396 (Collect lang items from AST, get rid of `GenericBound::LangItemTrait`)
- #118727 (Don't pass lint back out of lint decorator)
- #118956 (Make CStr documentation consistent ("nul" instead of "null"))
- #118981 (Remove an unneeded allocation)
- #118998 (Link to is_benchmark from the Ipv6Addr::is_global documentation)
r? `@ghost`
`@rustbot` modify labels: rollup
Link to is_benchmark from the Ipv6Addr::is_global documentation
All other relevant is_* methods are mentioned in the list of addresses here, is_benchmarking has been the only one missing.
Make CStr documentation consistent ("nul" instead of "null")
"nul" is used in method names and appears more often in the documentation than "null", so make all instances "nul" to keep it consistent.
Don't pass lint back out of lint decorator
Change the decorator function in the signature of the `emit_lint`/`span_lint`/etc family of methods from `impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>` to `impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>)`. I consider it easier to read this way, especially when there's control flow involved.
r? nnethercote though feel free to reassign
Collect lang items from AST, get rid of `GenericBound::LangItemTrait`
r? `@cjgillot`
cc #115178
Looking forward, the work to remove `QPath::LangItem` will also be significantly more difficult, but I plan on doing it as well. Specifically, we have to change:
1. A lot of `rustc_ast_lowering` for things like expr `..`
2. A lot of astconv, since we actually instantiate lang and non-lang paths quite differently.
3. A ton of diagnostics and clippy lints that are special-cased via `QPath::LangItem`
Meanwhile, it was pretty easy to remove `GenericBound::LangItemTrait`, so I just did that here.
Rollup of 7 pull requests
Successful merges:
- #117824 (Stabilize `ptr::{from_ref, from_mut}`)
- #118234 (Stabilize `type_name_of_val`)
- #118944 (Move type relations into submodule `relate` in rustc_infer, and notify when it has changed)
- #118977 (Simplify `src-script.js` code)
- #118985 (Remove `@JohnTitor` from diagnostics pings)
- #118986 (Simplify JS code a little bit)
- #118988 (rustdoc: add regression test for JS data file loading)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove @JohnTitor from diagnostics pings
I've been inactive around diagnostics for a while so would like to remove myself from the diagnostics-related ping groups for now.
Simplify `src-script.js` code
Instead of keeping this value in the global scope and still use it in the function in case it wasn't used outside, let's just use it inside the function.
r? ``@notriddle``
Stabilize `type_name_of_val`
Make the following API stable:
```rust
// in core::any
pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str
```
This is a convenience method to get the type name of a value, as opposed to `type_name` that takes a type as a generic.
Const stability is not added because this relies on `type_name` which is also not const. That has a blocking issue https://github.com/rust-lang/rust/issues/97156.
Wording was also changed to direct most of the details to `type_name` so we don't have as much duplicated documentation.
Fixes tracking issue #66359.
There were two main concerns in the tracking issue:
1. Naming: `type_name_of` and `type_name_of_val` seem like the only mentioned options. Differences in opinion here come from `std::mem::{size_of, align_of, size_of_val, align_of_val}`. This PR leaves the name as `type_name_of_val`, but I can change if desired since it is pretty verbose.
2. What this displays for `&dyn`: I don't think that having `type_name_of_val` function resolve those is worth the headache it would be, see https://github.com/rust-lang/rust/issues/66359#issuecomment-1718480774 for some workarounds. I also amended the docs wording to leave it open-ended, in case we have means to change that behavior in the future.
``@rustbot`` label -T-libs +T-libs-api +needs-fcp
r? libs-api
Stabilize `ptr::{from_ref, from_mut}`
I propose to stabilize the following APIs:
```rust
// mod core::ptr
pub const fn from_ref<T: ?Sized>(r: &T) -> *const T;
pub const fn from_mut<T: ?Sized>(r: &mut T) -> *mut T;
```
Tracking issue: https://github.com/rust-lang/rust/issues/106116
---
``@RalfJung`` what do you think we should do with `from_mut`? Stabilize it as const, given that you can't call it anyway (no way to get `&mut` in `const fn`)? Defer stabilizing it as const leaving the same issue/feature? Change issue/feature? Change issue/feature to the "`&mut` in const fn" one?
