pin a version of serde without intransparent unreproducible binary blobs
Serde is [shipping a binary blob in its derive crate](https://github.com/serde-rs/serde/issues/2538), which is highly unexpected and subverts user trust. To make matters worse, the binary is [not even reproducible](https://github.com/serde-rs/serde/issues/2575), making the crate largely unauditable and relinquishing the security benefits of open-source software. Build times are not nearly painful enough to justify forcing users to trust binary blobs.
coverage: Give the instrumentor its own counter type, separate from MIR
Within the MIR representation of coverage data, `CoverageKind` is an important part of `StatementKind::Coverage`, but the `InstrumentCoverage` pass also uses it heavily as an internal data structure. This means that any change to `CoverageKind` also needs to update all of the internal parts of `InstrumentCoverage` that manipulate it directly, making the MIR representation difficult to modify.
---
This change fixes that by giving the instrumentor its own `BcbCounter` type for internal use, which is then converted to a `CoverageKind` when injecting coverage information into MIR.
The main change is mostly mechanical, because the initial `BcbCounter` is drop-in compatible with `CoverageKind`, minus the unnecessary `CoverageKind::Unreachable` variant.
I've then removed the `function_source_hash` field from `BcbCounter::Counter`, as a small example of how the two types can now usefully differ from each other. Every counter in a MIR-level function should have the same source hash, so we can supply the hash during the conversion to `CoverageKind::Counter` instead.
---
*Background:* BCB stands for “basic coverage block”, which is a node in the simplified control-flow graph used by coverage instrumentation. The instrumentor pass uses the function's actual MIR control-flow graph to build a simplified BCB graph, then assigns coverage counters and counter expressions to various nodes/edges in that simplified graph, and then finally injects corresponding coverage information into the underlying MIR.
Fix a stack overflow with long else if chains
This fixes stack overflows when running the `issue-74564-if-expr-stack-overflow.rs` test with the parallel compiler.
Add MIR validation for unwind out from nounwind functions + fixes to make validation pass
`@Nilstrieb` This is the MIR validation you asked in https://github.com/rust-lang/rust/pull/112403#discussion_r1222739722.
Two passes need to be fixed to get the validation to pass:
* `RemoveNoopLandingPads` currently unconditionally introduce a resume block (even there is none to begin with!), changed to not do that
* Generator state transform introduces a `assert` which may unwind, and its drop elaboration also introduces many new `UnwindAction`s, so in this case run the AbortUnwindingCalls after the transformation.
I believe this PR should also fixRust-for-Linux/linux#1016, cc `@ojeda`
r? `@Nilstrieb`
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
