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://imgur.com/XnH4eeT) [](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
add lint for recreation of an entire struct
This lint makes Clippy warn about situations where an owned struct is
essentially recreated by moving all its fields into a new instance of
the struct. The lint is not machine-applicable because the source
struct may have been partially moved.
This lint originated in something I spotted during peer review. While
working on their branch a colleague ended up with a commit where a
function returned a struct that 1:1 replicated one of its owned inputs
from its members. Initially I suspected they hadn’t run their code
through Clippy but AFAICS there is no lint for this situation yet.
changelog: new lint: [`redundant_owned_struct_recreation`]
### New lint checklist
- \[+] Followed [lint naming conventions][lint_naming]
- \[+] Added passing UI tests (including committed `.stderr` file)
- \[+] `cargo test` passes locally
- \[+] Executed `cargo dev update_lints`
- \[+] Added lint documentation
- \[+] Run `cargo dev fmt`
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
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
With the previous improvements, it is now possible to run float parsing
tests as part of CI. Enable it here.
This only runs a subset of tests, which takes about one minute.
Oli Scherer
