Remove unqualified form import of io::Error in process_vxworks.rs and fallback on remove_dir_impl for vxworks
Hi all,
This is to address issue #127084. On inspections it was found that io::Error refrences were all of qualified form and there was no need to add a unqualified form import. Also to successfully build rust for vxworks, we need to fallback on the remove_impl_dir implementations.
Thank you.
Optimize SipHash by reordering compress instructions
This PR optimizes hashing by changing the order of instructions in the sip.rs `compress` macro so the CPU can parallelize it better. The new order is taken directly from Fig 2.1 in [the SipHash paper](https://eprint.iacr.org/2012/351.pdf) (but with the xors moved which makes it a little faster). I attempted to optimize it some more after this, but I think this might be the optimal instruction order. Note that this shouldn't change the behavior of hashing at all, only statements that don't depend on each other were reordered.
It appears like the current order hasn't changed since its [original implementation from 2012](fada46c421 (diff-b751133c229259d7099bbbc7835324e5504b91ab1aded9464f0c48cd22e5e420R35)) which doesn't look like it was written with data dependencies in mind.
Running `./x bench library/core --stage 0 --test-args hash` before and after this change shows the following results:
Before:
```
benchmarks:
hash::sip::bench_bytes_4 7.20/iter +/- 0.70
hash::sip::bench_bytes_7 9.01/iter +/- 0.35
hash::sip::bench_bytes_8 8.12/iter +/- 0.10
hash::sip::bench_bytes_a_16 10.07/iter +/- 0.44
hash::sip::bench_bytes_b_32 13.46/iter +/- 0.71
hash::sip::bench_bytes_c_128 37.75/iter +/- 0.48
hash::sip::bench_long_str 121.18/iter +/- 3.01
hash::sip::bench_str_of_8_bytes 11.20/iter +/- 0.25
hash::sip::bench_str_over_8_bytes 11.20/iter +/- 0.26
hash::sip::bench_str_under_8_bytes 9.89/iter +/- 0.59
hash::sip::bench_u32 9.57/iter +/- 0.44
hash::sip::bench_u32_keyed 6.97/iter +/- 0.10
hash::sip::bench_u64 8.63/iter +/- 0.07
```
After:
```
benchmarks:
hash::sip::bench_bytes_4 6.64/iter +/- 0.14
hash::sip::bench_bytes_7 8.19/iter +/- 0.07
hash::sip::bench_bytes_8 8.59/iter +/- 0.68
hash::sip::bench_bytes_a_16 9.73/iter +/- 0.49
hash::sip::bench_bytes_b_32 12.70/iter +/- 0.06
hash::sip::bench_bytes_c_128 32.38/iter +/- 0.20
hash::sip::bench_long_str 102.99/iter +/- 0.82
hash::sip::bench_str_of_8_bytes 10.71/iter +/- 0.21
hash::sip::bench_str_over_8_bytes 11.73/iter +/- 0.17
hash::sip::bench_str_under_8_bytes 10.33/iter +/- 0.41
hash::sip::bench_u32 10.41/iter +/- 0.29
hash::sip::bench_u32_keyed 9.50/iter +/- 0.30
hash::sip::bench_u64 8.44/iter +/- 1.09
```
I ran this on my computer so there's some noise, but you can tell at least `bench_long_str` is significantly faster (~18%).
Also, I noticed the same compress function from the library is used in the compiler as well, so I took the liberty of copy-pasting this change to there as well.
Thanks `@semisol` for porting SipHash for another project which led me to notice this issue in Rust, and for helping investigate. <3
Stabilize `PanicInfo::message()` and `PanicMessage`
Resolves#66745
This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).
Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]
extern crate libc;
#[no_mangle]
extern "C" fn main() -> libc::c_int {
panic!("I just panic every time");
}
#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
use arrayvec::ArrayString;
use core::fmt::Write;
let message = panic_info.message();
let location = panic_info.location().unwrap();
let mut debug_msg = ArrayString::<1024>::new();
let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");
if debug_msg.try_push_str("\0").is_ok() {
unsafe {
libc::puts(debug_msg.as_ptr() as *const _);
}
}
unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```
- [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725
r? libs-api
In 126578 we ended up with more binary size increases than expected.
This change attempts to avoid inlining large things into small things, to avoid that kind of increase, in cases when top-down inlining will still be able to do that inlining later.
Cleanup bootstrap check-cfg
This PR cleanup many custom `check-cfg` in bootstrap that have been accumulated over the years.
As well as updating some outdated comments.
small correction to fmt::Pointer impl
~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~
`expose_provenance` does not require `T: Sized`.
Print `TypeId` as a `u128` for `Debug`
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is represented as a `(u64, u64)`. This also made the debug implementation a lot larger, which is especially apparent with pretty formatting.
Change this to convert the inner value back to a `u128` and then print as a tuple struct to make this less noisy.
Current:
TypeId { t: (1403077013027291752, 4518903163082958039) }
TypeId {
t: (
1403077013027291752,
4518903163082958039,
),
}
New:
TypeId(25882202575019293479932656973818029271)
TypeId(
25882202575019293479932656973818029271,
)
Small fixme in core now that split_first has no codegen issues
https://github.com/rust-lang/rust/issues/109328#issuecomment-1677366881
BTW, I have a crate implementing exactly this kind of an iterator: https://github.com/GrigorenkoPV/head-tail-iter and I was wondering if it would be worthwhile to try and make an ACP for it to get it included in std (or maybe itertools). My only doubt is that it kinda incentives writing O(n^2) algorithms and is not the hard to replace with a `while let` loop (just as in this PR).
Rollup of 9 pull requests
Successful merges:
- #123237 (Various rustc_codegen_ssa cleanups)
- #126960 (Improve error message in tidy)
- #127002 (Implement `x perf` as a separate tool)
- #127081 (Add a run-make test that LLD is not being used by default on the x64 beta/stable channel)
- #127106 (Improve unsafe extern blocks diagnostics)
- #127110 (Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.)
- #127114 (fix: prefer `(*p).clone` to `p.clone` if the `p` is a raw pointer)
- #127118 (Show `used attribute`'s kind for user when find it isn't applied to a `static` variable.)
- #127122 (Remove uneccessary condition in `div_ceil`)
r? `@ghost`
`@rustbot` modify labels: rollup
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is
represented as a `(u64, u64)`. This also made the debug implementation a
lot larger, which is especially apparent with pretty formatting.
Make this less noisy by converting the inner value back to a `u128` then
printing as a tuple struct.
Current:
TypeId { t: (1403077013027291752, 4518903163082958039) }
TypeId {
t: (
1403077013027291752,
4518903163082958039,
),
}
New:
TypeId(25882202575019293479932656973818029271)
TypeId(
25882202575019293479932656973818029271,
)
Remove uneccessary condition in `div_ceil`
Previously, `div_ceil` for unsigned integers had a `rhs > 0` for rounding. That condition however is always fulfilled, since `rhs == 0` would mean a division by zero earlier.
Implement new effects desugaring
cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.
* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide
Fixes#119717Fixes#123664Fixes#124857Fixes#126148
docs: say "includes" instead of "does include"
Provides more visual difference between the negative ("does not include") and the positive ("includes"). Both phrases have the same meaning.
std: separate TLS key creation from TLS access
Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.
Related to #110897.
core: avoid `extern type`s in formatting infrastructure
```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837):
>How attached are y'all to using `extern type` in the formatting machinery?
Seems like this was introduced a [long time ago](34ef8f5441). However, it's also [not really compatible with Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/issues/256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](https://github.com/rust-lang/rust/issues/126814#issuecomment-2183816373) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere...
>
> The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`).
This PR does just that.
r? ```@RalfJung```
