Add functions to `GrowableBitSet`
Only really need `insert_range` for clippy, but may as well add the others. Using `Range` instead of `RangeBounds` since an end bound is needed for this to make sense and there aren't any traits to enforce that.
delegation: don't propagate synthetic params, remove lifetime hacks
Some small fixes after new delegation lowering was merged: remove lifetime hacks as now we get only early-bound lifetimes from generics, don't propagate synthetic generic params as now we know that they are synthetic. Fixesrust-lang/rust#143498. Part of rust-lang/rust#118212.
r? @petrochenkov
delegation: fix zero-args nested delegation ICE
This PR fixes an ICE when during lowering of nested delegation we need to access information about its parent, who is also inside body of another delegation. As a fix we lower delegation body even if there are no arguments in signature function, in this case we will see an error `this function takes 0 arguments but 1 argument was supplied`. Fixesrust-lang/rust#154332. Part of rust-lang/rust#118212.
r? @petrochenkov
Overhaul `Erasable` impls
This PR removes many unused `Erasable` impls, converts many of the hand-written impls to macro-generated impls, and sorts the macro's inputs. This cuts over 200 lines of code and fixes three FIXME comments.
r? @petrochenkov
miri recursive validation: only check one layer deep
As has been proposed in https://github.com/rust-lang/unsafe-code-guidelines/issues/414, let's see what happens if we make recursive checking in Miri shallow: we treat whatever is behind a reference as if it was inside `MaybeDangling`, which means nested references do not have to be dereferenceable.
This changes the meaning of the original flag -- I don't think it is worth supporting multiple variants of recursive checking (it'd require a bunch of new plumbing), and this seems to be the strictest variant that still has any traction in the discussion.
interpret: when passing an argument fails, point at that argument
For a long time now, we did some contortions so that when something goes wrong while initializing the arguments for a function, we point at the call site rather than the callee. Historically, this had to be done because the "current location" in the callee pointed at the first instruction, which would obviously be nonsense. A while ago we gained the ability in the interpreter for the "current location" to be just a span that we point at for errors, but we never reevaluated the decision for how spans are handled during function calls. (We did use this "just a span" location for [errors during the initial stack frame setup](https://github.com/rust-lang/rust/commit/d21e0118d0eefc8b0073fa47fa16699d37047abf), but not for argument initialization.)
There's no always-great choice for pointing at the caller vs the callee: when they disagree about the type of an argument, either side could be wrong. If We do *two* typed copies in that case, one at the caller type and one at the callee type. Arguably we should point at the one that goes wrong, but we don't have a good way to expose that.
What ultimately pushed me over the edge towards pointing at the callee are two points:
- This provides strictly more information. if we point at the callee, the caller is available in the stacktrace. But if we point at the caller, then it might be impossible to figure out the actual callee if a function pointer or dyn call is involved.
- As part of resolving some long-standing questions around retags I am moving retagging to become part of validation, which means the retag and protector initialization of function arguments will happen during argument initialization. These currently point at the argument inside the callee, which I think is strictly preferable for these errors.
The diff will be much smaller with whitespace changes hidden.
debuginfo: emit DW_TAG_call_site entries
Set `FlagAllCallsDescribed` on function definition DIEs so LLVM emits DW_TAG_call_site entries, letting debuggers and analysis tools track tail calls.
Add macro matcher for `guard` fragment specifier
Tracking issue #153104
This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)
The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Add `-Zsanitize=kernel-hwaddress`
The Linux kernel has a config option called `CONFIG_KASAN_SW_TAGS` that enables `-fsanitize=kernel-hwaddress`. This is not supported by Rust.
One slightly awkward detail is that `#[sanitize(address = "off")]` applies to both `-Zsanitize=address` and `-Zsanitize=kernel-address`. Probably it was done this way because both are the same LLVM pass. I replicated this logic here for hwaddress, but it might be undesirable.
Note that `#[sanitize(kernel_hwaddress = "off")]` could be supported as an annotation on statics, but since it's also missing for `#[sanitize(hwaddress = "off")]`, I did not add it.
MCP: https://github.com/rust-lang/compiler-team/issues/975
Tracking issue: https://github.com/rust-lang/rust/issues/154171
cc @rcvalle @maurer @ojeda
Some of the hand-written `Erasable` impls only match a single type in
practice. It's easier to just list the concrete types in
`impl_erasable_for_types_with_no_type_params!`.
Now that 'static lifetimes aren't used, a lot of the hand-written
`Erasable` impls can now be done with the macro. (The only ones that
can't are those with a generic type parameter, because `size_of`
doesn't work in that case.)
Also, `impl_erasable_for_single_lifetime_types!` isn't needed at all.
constify const Fn*: Destruct
makes closures const destruct where their upvars are. i think this makes sense
and is how this should be implemented.
r? @oli-obk
Unalign `PackedFingerprint` on all hosts, not just x86 and x86-64
Back in https://github.com/rust-lang/rust/pull/78646, `DepNode` was modified to store an unaligned `PackedFingerprint` instead of an 8-byte-aligned `Fingerprint`. That reduced the size of DepNode from 24 bytes to 17 bytes (nowadays 18 bytes), resulting in considerable memory savings in incremental builds.
See https://github.com/rust-lang/rust/pull/152695#issuecomment-3907091509 for a benchmark demonstrating the impact of *removing* that optimization.
At the time (and today), the unaligning was only performed on x86 and x86-64 hosts, because those CPUs are known to generally have low overhead for unaligned memory accesses. Hosts with other CPU architectures would continue to use an 8-byte-aligned fingerprint and a 24-byte DepNode.
Given the subsequent rise of aarch64 (especially on macOS) and other architectures, it's a shame that some commonly-used builds of rustc don't get those memory-size benefits, based on a decision made several years ago under different circumstances.
We don't have benchmarks to show the actual effect of unaligning DepNode fingerprints on various non-x86 hosts, but it seems very likely to be a good idea on Apple chips, and I have no particular reason to think that it will be catastrophically bad on other hosts. And we don't typically perform this kind of speculative pessimization in other parts of the compiler.
Delegation: eliminate usage of AST from generics creation
This PR eliminates all interaction with AST during creation of generics, then it supports proper const param types propagation. Fixesrust-lang/rust#153433. Fixesrust-lang/rust#153499. Part of rust-lang/rust#118212.
r? @petrochenkov
fix/extend some mir-opt comments
Looks like CopyProp was refactored without updating that comment.
And for GVN, I think this is what you had in mind @cjgillot but would be great if you could have a look.
Defer codegen for the VaList Drop impl to actual uses
This allows compiling libcore with codegen backends that don't actually implement VaList like cg_clif.
Use a safe `BucketIndex` abstraction in `VecCache`
The current code for indexing into bucket arrays is quite tricky and unsafe, partly because it has to keep manually assuring the compiler that a bucket index is always less than 21.
By encapsulating that knowledge in a 21-value enum, we can make the code clearer and safer, without giving up performance.
Having a dedicated `BucketIndex` type could also help with further cleanups of `VecCache` indexing.
Link LLVM dynamically on aarch64-apple-darwin
Follow-up to rust-lang/rust#152768.
* Link LLVM dynamically on MacOS
* Fix a macOS LLVM dylib name mismatch
The current code for indexing into bucket arrays is quite tricky and unsafe,
partly because it has to keep manually assuring the compiler that a bucket
index is always less than 21.
By encapsulating that knowledge in a 21-value enum, we can make the code
clearer and safer, without giving up performance.
Having a dedicated `BucketIndex` type could also help with further cleanups of
`VecCache` indexing.
Don't store current-session side effects in `OnDiskCache`
This PR is a series of related cleanups to `OnDiskCache`, which is responsible for loading query return values (and side effects) that were serialized during the previous incremental-compilation session.
The primary change is to move the `current_side_effects` field out of OnDiskCache and into QuerySystem. That field was awkward because it was the only part of OnDiskCache state related to serializing the *current* compilation session, rather than loading values from the previous session.
The other commits should hopefully be straightforward.
r? nnethercote (or compiler)
Clean up query-forcing functions
This PR takes the `force_query` function, inlines it into its only caller `force_from_dep_node_inner`, and renames the resulting function to `force_query_dep_node`. Combining the functions became possible after the removal of `rustc_query_system`, because they are now in the same crate.
There are two other notable cleanups along the way:
- Removing an unhelpful assertion and its verbose comment
- The removed comment was originally added in https://github.com/rust-lang/rust/commit/0454a41, but is too verbose to be worth preserving inline.
- Removing a redundant cache lookup while forcing, as it is useless in the serial compiler and unnecessary (and probably unhelpful) in the parallel compiler
r? nnethercote
Jonathan Brouwer