Rollup of 9 pull requests
Successful merges:
- #117932 (Correct rustdoc section where we talk about rustdoc emitting errors on invalid code)
- #125990 (Rename `deprecated_safe` lint to `deprecated_safe_2024`)
- #127506 (rustc_target: add known safe s390x target features)
- #127820 (Rewrite and rename `issue-14698`. `issue-33329` and `issue-107094` `run-make` tests to rmake or ui)
- #127923 (Use reuse tool 4.0)
- #128008 (Start using `#[diagnostic::do_not_recommend]` in the standard library)
- #128036 (add more tests)
- #128051 (rustdoc: revert spacing change in item-table)
- #128059 (Add regression test for items list size (#128023))
r? `@ghost`
`@rustbot` modify labels: rollup
Start using `#[diagnostic::do_not_recommend]` in the standard library
This commit starts using `#[diagnostic::do_not_recommend]` in the standard library to improve some error messages. In this case we just hide a certain nightly only impl as suggested in #121521
The result in not perfect yet, but at least the `Yeet` suggestion is not shown anymore. I would consider that as a minor improvement.
Use reuse tool 4.0
This change upgrades us to reuse-tool 4.0.3, which has a new TOML format configuration instead of the old `.reuse/dep5` Debian-style file.
* Updated requirements file to install reuse-4.0.3
* Ran `reuse convert-dep5` to switch to new file format
* Switched over to `override` so the `REUSE.toml` file takes precedence over whatever random Copyright strings `reuse` finds in the source tree.
Should fix https://github.com/rust-lang/rust/issues/127361
Rewrite and rename `issue-14698`. `issue-33329` and `issue-107094` `run-make` tests to rmake or ui
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-msvc
rustc_target: add known safe s390x target features
This pull request adds known safe target features for s390x (aka IBM Z systems).
Currently, these features are unstable since stabilizing the target features requires submitting proposals.
The `vector` feature was added in IBM Z13 (`arch11`), and this is a SIMD feature for the newer IBM Z systems.
The `backchain` attribute is the IBM Z way of adding frame pointers like unwinding capabilities (the "frame-pointer" switch on IBM Z and IBM POWER platforms will add _emulated_ frame pointers to the binary, which profilers can't use for unwinding the stack).
Both attributes can be applied at the LLVM module or function levels. However, the `backchain` attribute has to be enabled for all the functions in the call stack to get a successful unwind process.
Uplift most type-system related error reporting from `rustc_infer` to `rustc_trait_selection`
Completes the major part of #127492. The only cleanup that's needed afterwards is to actually use normalization in favor of the callback where needed, and deleting `can_eq_shallow`.
r? lcnr
Sorry for the large diff! Would prefer if comments can be handled in a follow-up (unless they're absolutely dealbreakers) because it seems bitrotty to let this sit.
Now that we have reuse-tool 4.0, we no longer need to massage the JSON license data to collapse LLVM into a single copyright notice and license - reuse-tool can do it for us using an annotation in REUSE.toml.
This effectively reverts c6eb03b.
Clean up warnings + `unsafe_op_in_unsafe_fn` when building std for armv6k-nintendo-3ds
See #127747
ping `@AzureMarker` `@Meziu`
I could only find one instance needing an extra `unsafe` that was not also shared with many other `unix` targets (presumably these will get covered in larger sweeping changes, I didn't want to introduce churn that would potentially conflict with those). The one codepath I found is shared with `vita` however, so also pinging `@nikarh` `@pheki` `@zetanumbers` just to make sure they're aware of this change.
Also removed one unused import from `process_unsupported` which should simply fix the warning for any target that uses it.
Update wasi-sdk in CI to latest release
This commit updates the `wasi-sdk` download used by the `wasm32-wasi*` targets. The motivation for this commit is generally just "keep things up to date" and is not intended to cause any issues or differences from before, just a routine update.
Rewrite `test-float-parse` in Rust
Migrate from the currently broken Rust + Python `test-float-parse` to a Rust implementation. This newer version should be significantly faster (tests execute in parallel with threads, rather than series across multiple processes, which also eliminates the "...the worker processes are leaked and stick around forever" message), and should be significantly easier to extend to the new float types.
Since this is faster and hopefully more stable, we should be able to launch it with `x` and run the faster tests in CI.
Add missing try_new_uninit_slice_in and try_new_zeroed_slice_in
The methods for fallible slice allocation in a given allocator were missing from `Box`, which was an oversight according to https://github.com/rust-lang/wg-allocators/issues/130
This PR adds them as `try_new_uninit_slice_in` and `try_new_zeroed_slice_in`. I simply copy-pasted the implementations of `try_new_uninit_slice` and `try_new_zeroed_slice` and adusted doc comment, typings, and the allocator it uses internally.
Also adds missing punctuation to the doc comments of `try_new_uninit_slice` and `try_new_zeroed_slice`.
Related issue is https://github.com/rust-lang/rust/issues/32838 (Allocator traits and std::heap) *I think*. Also relevant is https://github.com/rust-lang/rust/issues/63291, but I did not add the corresponding `#[unstable]` proc macro, since `try_new_uninit_slice` and `try_new_zeroed_slice` are also not annotated with it.
Try to fix ICE from re-interning an AllocId with different allocation contents
As far as I can tell, based on my investigation in https://github.com/rust-lang/rust/issues/126741, the racy decoding scheme implemented here was never fully correct, but the arrangement of Allocations that's required to ICE the compiler requires some very specific MIR optimizations to create. As far as I can tell, GVN likes to create the problematic pattern, which is why we're noticing this problem now.
So the solution here is to not do racy decoding. If two threads race to decoding an AllocId, one of them is going to sit on a lock until the other is done.
This commit starts using `#[diagnostic::do_not_recommend]` in the
standard library to improve some error messages. In this case we just
hide a certain nightly only impl as suggested in #121521
Don't output incremental test artifacts into working directory
Currently tests can ICE when the test spits out `inc-fat` incremental artifacts directly into the top of the git checkout, and then the compiler version changes, and it reads nonsense incremental artifacts on a subsequent test run.
r? `@oli-obk`
cc `@Oneirical,` I think you added this -- I think the right flag to add when porting `-Cincremental` run-make tests is to use `//@ incremental` rather than manually specifying the `-Cincremental` rustflag.
Explain why we require `_` for empty patterns
This adds a note to the "non-exhaustive patterns" diagnostic to explain why we sometimes require extra `_` patterns on empty types. This is one of the two diagnostic improvements I wanted to do before [stabilizing `min_exhaustive_patterns`](https://github.com/rust-lang/rust/pull/122792).
r? ``@compiler-errors``
rustdoc: short descriptions cause word-breaks in tables
The `.item-table` class is used to display name+description lists, e.g. the exported functions, as a table. If the names are long and the descriptions are short, then the width of the table does not expand to the whole size, but only uses a fraction. This causes a some names to break inside a word.
This change makes the table always use 100% of its parent width. The `.width-limiter` wrapper already ensures that the used width still does not become excessive.
See e.g. <https://docs.rs/mathlab/0.3.0/mathlab/fun/vec_num/index.html> or <https://docs.rs/cw-events/0.0.9/cw_events/> (random choices out of the list of the recent releases).
[![](https://i.imgur.com/XnH4eeT.png)](https://imgur.com/XnH4eeT) [![](https://i.imgur.com/7iQ9xE2.png)](https://imgur.com/7iQ9xE2)
The problem occurs (at least) in Firefox 130, Falkon 24, and Konqueror 22. It does not occur in Chrome 126.
Just totally fully deny late-bound consts
Kinda don't care about supporting this until we have where clauses on binders. They're super busted and should be reworked in due time, and they are approximately 100% useless until then 😸Fixes#127970Fixes#127009
r? ``@BoxyUwU``
Deal with invalid UTF-8 from `gai_strerror`
When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
fixes#127563
Remove unnecessary impl sorting in queries and metadata
Removes unnecessary impl sorting because queries already return their keys in HIR definition order: https://github.com/rust-lang/rust/issues/120371#issuecomment-1926422838
r? `@cjgillot` or `@lcnr` -- unless I totally misunderstood what was being asked for here? 😆fixes#120371