Remove unused symbols and diagnostic items
As the title suggests, this removes unused symbols from `sym::` and `#[rustc_diagnostic_item]` annotations that weren't mentioned anywhere.
Originally I tried to use grep, to find symbols and item names that are never mentioned via `sym::name`, however this produced a lot of false positives (?), for example clippy matching on `Symbol::as_str` or macros "implicitly" adding `sym::`. I ended up fixing all these false positives (?) by hand, but tbh I'm not sure if it was worth it...
Update compiler-builtins
This was originally a part of https://github.com/rust-lang/rust/pull/100316. However, extracting it to a seperate PR should help with any extra testing that might be needed.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Rollup of 9 pull requests
Successful merges:
- #103709 (ci: Upgrade dist-x86_64-netbsd to NetBSD 9.0)
- #103744 (Upgrade cc for working is_flag_supported on cross-compiles)
- #104105 (llvm: dwo only emitted when object code emitted)
- #104158 (Return .efi extension for EFI executable)
- #104181 (Add a few known-bug tests)
- #104266 (Regression test for coercion of mut-ref to dyn-star)
- #104300 (Document `Path::parent` behavior around relative paths)
- #104304 (Enable profiler in dist-s390x-linux)
- #104362 (Add `delay_span_bug` to `AttrWrapper::take_for_recovery`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make all download functions need only Config, not Builder
This also adds a new `mod download` instead of scattering the download code across `config.rs` and `native.rs`.
This is the simplest and also most bit-rotty part of https://github.com/rust-lang/rust/pull/102282. Opening it earlier so it's not mixed in with behavior changes and to avoid rebase hell.
cc https://github.com/rust-lang/rust/issues/94829 (which nows has the hackmd linked).
r? `@Mark-Simulacrum`
Add `delay_span_bug` to `AttrWrapper::take_for_recovery`
`take_for_recovery` should only be used for recovery (when we should already have an error), so using `delay_span_bug` seems appropriate.
cc `@Aaron1011` (you've added the `FIXME` that this pr fixes)
Enable profiler in dist-s390x-linux
Build the profiler runtime to allow using -C profile-generate and -C instrument-coverage on s390x-linux.
I've verified in a local build that the runtime builds and the profiler is working fine on the platform.
Document `Path::parent` behavior around relative paths
A relative path with just one component will return `Some("")` as its parent, which wasn't clear to me from the documentation.
The parent of `""` is `None`, which was missing from the documentation as well.
Add a few known-bug tests
The labels of these tests should be changed from `S-bug-has-mcve` to `S-bug-has-test` once this is merged.
cc:
#101518#99492#90950#89196#104034#101350#103705#103899
I couldn't reproduce the failures in #101962 and #100772 (so either these have started passing, or I didn't repro properly), so leaving those out for now.
#102065 was a bit more complicated, since it uses `rustc_private` and I didn't want to mess with that.
llvm: dwo only emitted when object code emitted
Fixes#103932.
`CompiledModule` should not think a DWARF object was emitted when a bitcode-only compilation has happened, this can confuse archive file creation (which expects to create an archive containing non-existent dwo files).
r? ``````@michaelwoerister``````
ci: Upgrade dist-x86_64-netbsd to NetBSD 9.0
This is another step in toolchain upgrades for LLVM 16, which will need at least GCC 7.1.
Our previous NetBSD 8.0 cross-toolchain used its system GCC 5.5. While there are newer versions available in pkgsrc, I could not get those working for cross-compilation. Upgrading to NetBSD 9.0 gets us GCC 7.4, which is sufficient for now.
This will affect the compatibility of the build we ship for `x86_64-unknown-netbsd`, but others may still build their own from source if that is needed. It is expected that NetBSD 8 will reach EOL soon anyway, approximately one month after 10 is released, but there is no firm date for that.
Change the way libunwind is linked for *-windows-gnullvm targets
I have no idea why previous way works for `x86_64-fortanix-unknown-sgx` (assuming it actually works...) but not for `gnullvm`. It fails when linking libtest during Rust build (unless somebody adds `RUSTFLAGS='-Clinkarg=-lunwind'`).
Also fixes exception handling on AArch64.
Rollup of 5 pull requests
Successful merges:
- #103996 (Add small clarification around using pointers derived from references)
- #104315 (Improve spans with `use crate::{self}`)
- #104320 (Use `derive_const` and rm manual StructuralEq impl)
- #104357 (add is_sized method on Abi and Layout, and use it)
- #104365 (Add x tool to triagebot)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This was originally a part of https://github.com/rust-lang/rust/pull/100316.
However, extracting it to a seperate PR should help with any extra
testing that might be needed.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Use `derive_const` and rm manual StructuralEq impl
This does not change any semantics of the impl except for the const stability. It should be fine because trait methods and const bounds can never be used in stable without enabling `const_trait_impl`.
cc `@oli-obk`
Add small clarification around using pointers derived from references
r? `@RalfJung`
One question about your example from https://github.com/rust-lang/libs-team/issues/122: at what point does UB arise? If writing 0 does not cause UB and the reference `x` is never read or written to (explicitly or implicitly by being wrapped in another data structure) after the call to `foo`, does UB only arise when dropping the value? I don't really get that since I thought references were always supposed to point to valid data?
```rust
fn foo(x: &mut NonZeroI32) {
let ptr = x as *mut NonZeroI32;
unsafe { ptr.cast::<i32>().write(0); } // no UB here
// What now? x is considered garbage when?
}
```
Fix missing reexports' doc comments
Fixes#81893.
The issue was that an import directly "links" to the target without the intermediate imports. Unfortunately, to fix this bug we need to go through them one by one. To do so, I take the import path direct parent (so `b` in `a:🅱️:c`) and then look for `c` into it.
r? `@notriddle`
Merge crossbeam-channel into `std::sync::mpsc`
This PR imports the [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel#crossbeam-channel) crate into the standard library as a private module, `sync::mpmc`. `sync::mpsc` is now implemented as a thin wrapper around `sync::mpmc`. The primary purpose of this PR is to resolve https://github.com/rust-lang/rust/issues/39364. The public API intentionally remains the same.
The reason https://github.com/rust-lang/rust/issues/39364 has not been fixed in over 5 years is that the current channel is *incredibly* complex. It was written many years ago and has sat mostly untouched since. `crossbeam-channel` has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped.
Replacing `sync::mpsc` with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling *fearless concurrency*, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better.
As mentioned before, the primary purpose of this PR is to fix https://github.com/rust-lang/rust/issues/39364, and so the public API intentionally remains the same. *After* that problem is fixed, the fact that `sync::mpmc` now exists makes it easier to fix the primary limitation of `mpsc`, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating `mpsc` and exposing a general `sync::channel` module that supports multiple consumers. It also implements other useful methods such as `send_timeout`. That said, exposing MPMC and other new functionality is mostly out of scope for this PR, and it would be helpful if discussion stays on topic :)
For what it's worth, the new implementation has also been shown to be more performant in [some basic benchmarks](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel/benchmarks#results).
cc `@taiki-e`
r? rust-lang/libs
Fix up a Fluent message
Fix up a Fluent message which contained arrows `->` after [selectors](https://projectfluent.org/fluent/guide/selectors.html). The original author probably thought that they were required as part of the selector syntax but in reality they were interpreted as literal text and actually showed up in the emitted diagnostic.
This wasn't caught during the diagnostic migration since the branch constructing the diagnostic in question (`rustc_infer::errors::LifetimeMismatchLabels::Normal`) was not exercised by the UI test suite. I've added two more test cases to do so (one testing `LifetimeMismatchLabels::Normal` where `hir_equal == true` and one where `hir_equal == false`).
Diff visualizing the `->` bug (`master` vs `fix-up-a-fluent-message`):
```diff
error[E0623]: lifetime mismatch
--> src/test/ui/implied-bounds/hrlt-implied-trait-bounds-guard.rs:39:30
|
39 | fn badboi3<'in_, 'out, T>(a: Foo<'in_, 'out, (&'in_ T, &'out T)>, sadness: &'in_ T) {
| ^^^^^^^^^^^^^^^^^-------^^-------^^
| | |
| | these two types are declared with different lifetimes...
- | ...but data-> from `a` flows-> into `a` here
+ | ...but data from `a` flows into `a` here
```
