custom_mir: change Call() terminator syntax to something more readable
I find our current syntax very hard to read -- I cannot even remember the order of arguments, and having the "next block" *before* the actual function call is very counter-intuitive IMO. So I suggest we use `Call(ret_val = function(v), next_block)` instead.
r? `@JakobDegen`
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
This test needed more cleanup: first I removed duplication by using a function, then I merge similar rules which had the same values.
r? `@notriddle`
Ignore unexpected incr-comp session dirs
Clearly the code path can be hit without the presence of a compiler bug.
All it takes is mischief. See #71698.
Ignore problematic directories instead of ICE:ing. `continue`ing is
already done for problematic dirs in the code block above us.
Closes#71698.
With this fix, the output is this instead of ICE:
```
$ cargo +stage1 new gz-ice && cd gz-ice
$ cargo +stage1 build
$ find target -type f -exec gzip {} \;
$ cargo +stage1 run
Created binary (application) `gz-ice` package
Compiling gz-ice v0.1.0 (/tmp/gz-ice)
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
gzip: target/debug/gz-ice has 1 other link -- unchanged
gzip: target/debug/deps/gz_ice-de919414dd9926b9 has 1 other link -- unchanged
Compiling gz-ice v0.1.0 (/tmp/gz-ice)
warning: failed to garbage collect invalid incremental compilation session directory `/tmp/gz-ice/target/debug/incremental/gz_ice-23qx9z9j9vghe/s-gnwd8daity-kp10sj.lock.gz`: Not a directory (os error 20)
warning: `gz-ice` (bin "gz-ice") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
Running `target/debug/gz-ice`
Hello, world!
```
Fix UB in `std::sys::os::getenv()`
Fixes#114949.
Reduced the loops to 1k iterations (100k was taking way too long), Miri no longer shows any UB.
`@rustbot` label +A-process +C-bug +I-unsound +O-unix
Avoid side-effects from `try_coerce` when suggesting borrowing LHS of cast
The name `try_coerce` is a bit misleading -- it has side-effects, so when it's used in diagnostics code, it sometimes causes spurious obligations to be registered which cause other errors to occur that really make no sense in context.
Addendum: let's just rename `try_coerce` to `coerce` -- the `try_` part doesn't really add much, imo.
Normalize return type of `deduce_future_output_from_obligations`
Fixes#114909
Also confirmed to fix#114727 manually
Now that we have weak/lazy type aliases, we need to normalize those in future signatures to ensure that `replace_opaque_types_with_inference_vars` actually sees TAITs behind them. This isn't needed in the new solver, but added a test to make sure it doesn't regress there either.
r? types cc `@oli-obk` (who's gone, worst case can delay this PR until he's back)
Fix ABI flags in RISC-V/LoongArch ELF file generated by rustc
Fix#114153
It turns out the current way to set these flags are completely wrong. In LLVM the target ABI is used instead of target features to determine these flags.
Not sure how to write a test though. Or maybe a test isn't necessary because this affects only those touching target json?
r? `@Nilstrieb`
This shows one small benefit of separating `BcbCounter` from `CoverageKind`.
The function source hash will be the same for all counters within a function,
so instead of passing it through `CoverageCounters` and storing it in every
counter, we can just supply it during the final conversion to `CoverageKind`.
rustdoc: Add lint `redundant_explicit_links`
Closes#87799.
- Lint warns by default
- Reworks link parser to cache original link's display text
r? `@jyn514`
Rollup of 8 pull requests
Successful merges:
- #114605 (Increase clarity about Hash - Eq consistency in HashMap and HashSet docs)
- #114934 (instantiate response: no unnecessary new universe)
- #114950 (Inline strlen_rt in CStr::from_ptr)
- #114973 (Expose core::error::request_value in std)
- #114983 (Usage zero as language id for `FormatMessageW()`)
- #114991 (remove redundant var rebindings)
- #114992 (const-eval: ensure we never const-execute a function marked rustc_do_not_const_check)
- #115001 (clippy::perf stuff)
r? `@ghost`
`@rustbot` modify labels: rollup
Usage zero as language id for `FormatMessageW()`
This switches the language selection from using system language (note that this might be different than application language, typically stored as thread ui language) to use `FormatMessageW` default search strategy, which is `neutral` first, then `thread ui lang`, then `user language`, then `system language`, then `English`. (See https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessagew)
This allows the Rust program to take more control of `std::io::Error`'s message field, by setting up thread ui language themselves before hand (which many programs already do).
Inline strlen_rt in CStr::from_ptr
This enables LLVM to optimize this function as if it was strlen (LLVM knows what it does, and can avoid calling it in certain situations) without having to enable std-aware LTO. This is essentially doing what https://github.com/rust-lang/rust/pull/90007 did, except updated for this function being `const`.
Pretty sure it's safe to roll-up, considering last time I did make this change it didn't affect performance (`CStr::from_ptr` isn't really used all that often in Rust code that is checked by rust-perf).
Increase clarity about Hash - Eq consistency in HashMap and HashSet docs
As discussed [here](https://users.rust-lang.org/t/what-hapens-if-hash-and-partialeq-dont-match-when-using-hashmap/98052/13) the description of logic errors in `HashMap` and `HashSet` does not explicitly apply to
```text
k1 == k2 -> hash(k1) == hash(k2)
```
but this is likely what is intended.
This PR is a small doc change to correct this.
r? rust-lang/libs
fix: avoid problematic serde release
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the crate.
As such, I am willing to go on a limb here and forbid building rust-analyzer with those versions of serde. Normally, my philosophy is to defer the choice to the end user, but it's also a design constraint of rust-analyzer that we don't run random binaries downloaded from the internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as well as the lsp-server lib.
See https://github.com/serde-rs/serde/issues/2538 for wider context.
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to
function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the
crate.
As such, I am willing to go on a limb here and forbid building
rust-analyzer with those versions of serde. Normally, my philosophy is
to defer the choice to the end user, but it's also a design constraint
of rust-analyzer that we don't run random binaries downloaded from the
internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as
well as the lsp-server lib.
See https://github.com/serde-rs/serde/issues/2538 for wider context.
Rollup of 5 pull requests
Successful merges:
- #114953 (Add myself back to review rotation)
- #114958 (`ignore-cross-compile` on `optimization-remarks-dir-pgo` test)
- #114971 (Add doc aliases for trigonometry and other f32,f64 methods.)
- #114972 (Add a test to check that inline const is in required_consts)
- #114977 (Add `modulo` and `mod` as doc aliases for `rem_euclid`.)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `modulo` and `mod` as doc aliases for `rem_euclid`.
When I was learning Rust I looked for “a modulo function” and couldn’t find one, so thought I had to write my own; it wasn't at all obvious that a function with “rem” in the name was the function I wanted. Hopefully this will save the next learner from that.
However, it does have the disadvantage that the top results in rustdoc for “mod” are now these aliases instead of the Rust keyword, which probably isn't ideal.
Add doc aliases for trigonometry and other f32,f64 methods.
These are common alternate names, usually a less-abbreviated form, for the operation; e.g. `arctan` instead of `atan`. Prompted by <https://users.rust-lang.org/t/64-bit-trigonometry/98599>
`ignore-cross-compile` on `optimization-remarks-dir-pgo` test
We noticed this on our upstream pull on ferrocene a week ago as it was failing our CI. The test attempts to run the produced binary which won't work when cross compiling.
