We haven't been compressing dylib metadata for a while now. Removing
decompression support will regress error messages about an incompatible
rustc version being used, but dylibs are pretty rare anyway.
coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable
In #132124, `coverage_cx()` was changed to panic if the context was unavailable, under the assumption that it would always be available whenever coverage instrumentation is enabled.
However, there have been reports of this change causing ICEs in `polars` CI.
I don't yet understand why this is happening, but for now it seems wisest to revert that part of the change, restoring the two early returns that had been replaced with panics.
Add `lp64e` RISC-V ABI
This PR adds support for the `lp64e` RISC-V ABI, which is the 64-bit equivalent of the `ilp32e` ABI that is already supported.
For reference, this ABI was originally added to LLVM in [this PR](https://reviews.llvm.org/D70401).
Remove region from adjustments
It's not necessary to store this region, because it's only used in THIR and MemCat/ExprUse, both of which already basically only deal with erased regions anyways.
Rollup of 4 pull requests
Successful merges:
- #132347 (Remove `ValueAnalysis` and `ValueAnalysisWrapper`.)
- #132365 (pass `RUSTC_HOST_FLAGS` at once without the for loop)
- #132366 (Do not enforce `~const` constness effects in typeck if `rustc_do_not_const_check`)
- #132376 (Annotate `input` reference tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not enforce `~const` constness effects in typeck if `rustc_do_not_const_check`
Fixes a slight inconsistency between HIR and MIR enforcement of `~const` :D
r? `@rust-lang/project-const-traits`
Remove `ValueAnalysis` and `ValueAnalysisWrapper`.
They represent a lot of abstraction and indirection, but they're only used for `ConstAnalysis`, and apparently won't be used for any other analyses in the future. This commit inlines and removes them, which makes `ConstAnalysis` easier to read and understand.
r? `@cjgillot`
Try to point out when edition 2024 lifetime capture rules cause borrowck issues
Lifetime capture rules in 2024 are modified to capture more lifetimes, which sometimes lead to some non-local borrowck errors. This PR attempts to link these back together with a useful note pointing out the capture rule changes.
This is not a blocking concern, but I'd appreciate feedback (though, again, I'd like to stress that I don't want to block this PR on this): I'm worried about this note drowning in the sea of other diagnostics that borrowck emits. I was tempted to change the level of the note to `.span_warn` just so it would show up in a different color. Thoughts?
Fixes#130545
Opening as a draft first since it's stacked on #131183.
r? `@ghost`
They represent a lot of abstraction and indirection, but they're only
used for `ConstAnalysis`, and apparently won't be used for any other
analyses in the future. This commit inlines and removes them, which
makes `ConstAnalysis` easier to read and understand.
Make sure `type_param_predicates` resolves correctly for RPITIT
After #132194, we end up lowering the item bounds for an RPITIT in an `ItemCtxt` whose def id is the *synthetic GAT*, not the opaque type from the HIR.
This means that when we're resolving a shorthand projection like `T::Assoc`, we call the `type_param_predicates` function with the `item_def_id` of the *GAT* and not the opaque. That function operates on the HIR, and is not designed to work with the `Node::Synthetic` that gets fed for items synthesized by the compiler...
This PR reuses the trick we use elsewhere in lowering, where we intercept whether an item comes from RPITIT lowering, and forwards the query off to the correct item.
Fixes#132372
Rename `rustc_abi::Abi` to `BackendRepr`
Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.
Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
Remap impl-trait lifetimes on HIR instead of AST lowering
Current AST->HIR lowering goes out of its way to remap lifetimes for opaque types. This is complicated and leaks into upstream and downstream code.
This PR stops trying to be clever during lowering, and prefers to do this remapping during the HIR->ty lowering. The remapping computation easily fits into the bound var resolution code. Its result can be used in by `generics_of` and `hir_ty_lowering::new_opaque` to add the proper parameters and arguments.
See an example on the doc for query `opaque_captured_lifetimes`.
Based on https://github.com/rust-lang/rust/pull/129244/
Fixes https://github.com/rust-lang/rust/issues/125249
Fixes https://github.com/rust-lang/rust/issues/126850
cc `@compiler-errors` `@spastorino`
r? `@petrochenkov`
Fix AIX libc call char type from i8 to u8
There was an update to AIX `libc` default char type from `i8 -> u8`, we should reflect that on the call site to satisfy the type checker.
81f0cd3d97/src/unix/aix/mod.rs (L1)
