`slice::sort_unstable` will fall back to heapsort if it repeatedly fails to find
a good pivot. By making the core child update code branchless it is much faster.
On Zen3 sorting 10k `u64` and forcing the sort to pick heapsort, results in:
455us -> 278us
internal: Revert castable expectation and simplify
Unfixes https://github.com/rust-lang/rust-analyzer/issues/11571, the PR for that introduced some regressions (tried fixing them but doing what rustc does there specifically does not help, probably because something else affects it as well there)
Rollup of 6 pull requests
Successful merges:
- #107789 (Avoid exposing type parameters and implementation details sourced from macro expansions)
- #107836 (Handle properly when there is no crate attrs)
- #107839 (avoid duplicating the RUSTC_LOG env var name)
- #107866 (Allow wasi-libc to initialize its environment variables lazily.)
- #107876 (create symlink only for non-windows operating systems)
- #107882 (Cleanup typos in en_US/borrowck.ftl)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
create symlink only for non-windows operating systems
Follow up on #107834
It's my first time using the #cfg attribute. Did I use it correctly?
Thank you!
Allow wasi-libc to initialize its environment variables lazily.
Use `__wasilibc_get_environ()` to read the environment variable list from wasi-libc instead of using `environ`. `environ` is a global variable which effectively requires wasi-libc to initialize the environment variables eagerly, and `__wasilibc_get_environ()` is specifically designed to be an alternative that lets wasi-libc intiailize its environment variables lazily.
This should have the side effect of fixing at least some of the cases of #107635.
avoid duplicating the RUSTC_LOG env var name
We also have the env var name here:
c40919b7a7/compiler/rustc_driver_impl/src/lib.rs (L1247-L1251)
Redundantly having this name twice doesn't seem great. Looks like `rustc_log::init_rustc_env_logger` is dead code anyway.
r? `@oli-obk`
Avoid exposing type parameters and implementation details sourced from macro expansions
Fixes#107745.
~~I would like to **request some guidance** for this issue, because I don't think this is a good fix (a band-aid at best).~~
### The Problem
The code
```rust
fn main() {
println!("{:?}", []);
}
```
gets desugared into (`rustc +nightly --edition=2018 issue-107745.rs -Z unpretty=hir`):
```rust
#[prelude_import]
use std::prelude::rust_2018::*;
#[macro_use]
extern crate std;
fn main() {
{
::std::io::_print(<#[lang = "format_arguments"]>::new_v1(&["",
"\n"], &[<#[lang = "format_argument"]>::new_debug(&[])]));
};
}
```
so the diagnostics code tries to be as specific and helpful as possible, and I think it finds that `[]` needs a type parameter and so does `new_debug`. But since `[]` doesn't have an origin for the type parameter definition, it points to `new_debug` instead and leaks the internal implementation detail since all `[]` has is an type inference variable.
### ~~The Bad Fix~~
~~This PR currently tries to fix the problem by bypassing the generated function `<#[lang = "format_argument"]>::new_debug` to avoid its generic parameter (I think it is auto-generated from the argument `[_; 0]`?) from getting collected as an `InsertableGenericArg`. This is problematic because it also prevents the help from getting displayed.~~
~~I think this fix is not ideal and hard-codes the format generated code pattern, but I can't think of a better fix. I have tried asking on Zulip but no responses there yet.~~
Clap was updated in rust-lang/rust-clippy#10270, which broke the command
line of clippy_dev. This swaps out contains_id, which now returns always
true in the places it was used with get_flag.
