Rename various query cycle things.
The existing names have bugged me for a while. Changes:
- `CycleError` -> `Cycle`. Because we normally use "error" for a `Diag` with `Level::Error`, and this type is just a precursor to that. Also, many existing locals of this type are already named `cycle`.
- `CycleError::cycle` -> `Cycle::frames`. Because it is a sequence of frames, and we want to avoid `Cycle::cycle` (and `cycle.cycle`).
- `cycle_error` -> `find_and_handle_cycle`. Because that's what it does. The existing name is just a non-descript noun phrase.
- `mk_cycle` -> `handle_cycle`. Because it doesn't make the cycle; the cycle is already made. It handles the cycle, which involves (a) creating the error, and (b) handling the error.
- `report_cycle` -> `create_cycle_error`. Because that's what it does: creates the cycle error (i.e. the `Diag`).
- `value_from_cycle_error` -> `handle_cycle_error_fn`. Because most cases don't produce a value, they just emit an error and quit. And the `_fn` suffix is for consistency with other vtable fns.
- `from_cycle_error` -> `handle_cycle_error`. A similar story for this module.
r? @petrochenkov
Every other part of `OnDiskCache` deals with loading information from the
_previous_ session, except for this one field.
Moving it out to `QuerySystem` makes more sense, because that's also where
query return values are stored (inside the caches in their vtables).
These lists can be considered part of the encoder state, and bundling them
inside the encoder is certainly more convenient than passing them around
separately.
Prior to #154122 it wasn't used on all paths, so we only computed it
when necessary -- sometimes in `check_if_ensure_can_skip_execution`,
sometimes in one of two places in `execute_job_incr` -- and pass around
`Option<DepNode>` to allow this.
But now it's always used, so this commit makes us compute it earlier,
which simplifies things.
- `check_if_ensure_can_skip_execution` can be made simpler, returning a
bool and eliminating the need for `EnsureCanSkip`.
- `execute_job_incr` no longer uses two slightly different methods to
create a `DepNode` (`get_or_insert_with` vs `unwrap_or_else`).
The call chain for a non-incremental query includes the following
functions:
- execute_query_non_incr_inner (assert!)
- try_execute_query (assert!)
- execute_job_non_incr (assert!)
And likewise for an incremental query:
- execute_query_incr_inner (assert!)
- try_execute_query (assert!)
- execute_job_incr (expect)
That is five distinct functions. Every one of them has an `assert!` or
`expect` call that checks that the dep-graph is/is not enabled as
expected. Three cheers for defensive programming but this feels like
overkill, particularly when `execute_job{,_non_incr,_incr}` each have a
single call site.
This commit removes the assertions in `execute_query_*` and
`try_execute_query`, leaving a check in each of the `execute_job_*`
functions.
The existing names have bugged me for a while. Changes:
- `CycleError` -> `Cycle`. Because we normally use "error" for a `Diag`
with `Level::Error`, and this type is just a precursor to that. Also,
many existing locals of this type are already named `cycle`.
- `CycleError::cycle` -> `Cycle::frames`. Because it is a sequence of
frames, and we want to avoid `Cycle::cycle` (and `cycle.cycle`).
- `cycle_error` -> `find_and_handle_cycle`. Because that's what it does.
The existing name is just a non-descript noun phrase.
- `mk_cycle` -> `handle_cycle`. Because it doesn't make the cycle; the
cycle is already made. It handles the cycle, which involves (a)
creating the error, and (b) handling the error.
- `report_cycle` -> `create_cycle_error`. Because that's what it does:
creates the cycle error (i.e. the `Diag`).
- `value_from_cycle_error` -> `handle_cycle_error_fn`. Because most
cases don't produce a value, they just emit an error and quit.
And the `_fn` suffix is for consistency with other vtable fns.
- `from_cycle_error` -> `handle_cycle_error`. A similar story for this
module.
Allow applying autodiff macros to trait functions.
It will use enzyme to generate a default derivative implementation, which can be overwritten by the user.
closes: https://github.com/rust-lang/rust/issues/153329
r? @JonathanBrouwer
const validity checking: do not recurse to references inside MaybeDangling
This arguably should be allowed, but we currently reject it:
```rust
#![feature(maybe_dangling)]
use std::mem::MaybeDangling;
const X: MaybeDangling<&bool> = unsafe { std::mem::transmute(&5u8) };
```
r? @WaffleLapkin
Avoid prematurely choosing a glob import
Fixes rust-lang/rust#153842
Use the following without introducing trait to explain:
```rust
mod a {
pub use crate::x::y as x; // single import #1
}
mod b {
pub mod x {
pub mod y {}
}
}
use a::x; // single import #2
use b::*; // glob import #3
fn main() {}
```
In current implementation, when `#1` is first resolved, `crate::x` is temporarily taken from glob import `#3` as `crate::b::x`. This happens because `single_import_can_define_name` will see that `#2` cannot define `x` (because it depends on `#1` and `#1` is ignored) and then return `false`. Later, during finalization, `crate::x` in `#1` resolves through single import `#2` instead, which no longer matches the initially cached module `crate::b::x` and triggers the ICE.
I think the resolver should keep this unresolved because `#2` may still define `x` to avoid prematurely choosing a glob import.
r? petrochenkov
Remove `ATTRIBUTE_ORDER`
r? @jdonszelmann
There's only a few attributes that use `KeepInnermost` and I think I like the consistency of just making them all `KeepOutermost`
Always check `ConstArgHasType` even when otherwise ignoring
fixes https://github.com/rust-lang/rust/issues/149774
helping @BoxyUwU finish up https://github.com/rust-lang/rust/pull/150322, this is a simple tweak/finishing-up of that PR.
this is a breaking change that crater detected has some issues with in Boxy's PR, and hence needs a t-types FCP. I can go and help fix those crates if/once the break is signed off on.
Use enums to clarify `DepNodeColorMap` color marking
When a function's documentation has to explain the meaning of nested results and options, then it is often a good candidate for using a custom result enum instead.
This PR also renames `DepNodeColorMap::try_mark` to `try_set_color`, to make it more distinct from the similarly-named `DepGraph::try_mark_green`.
The difference is that `try_mark_green` is a higher-level operation that tries to determine whether a node _can_ be marked green, whereas `try_set_color` is a lower-level operation that actually records a colour for the node.
The updated docs for `try_set_color` also fix a typo: *atomicaly* → *atomically*.
r? nnethercote (or compiler)
Update the tracking issue for #[diagnostic::on_move]
PR rust-lang/rust#150935 has been merged and then I have opened the tracking issue (whoops ?). So this update `compiler/rustc_feature/src/unstable.rs` to point to the right tracking issue.
This is related to the tracking issue rust-lang/rust#154181
diagnostics: avoid ICE for undeclared generic parameter in impl
Avoid an ICE for:
struct A;
impl A<B> {}
The compiler no longer panics and can proceed to emit existing diagnostics.
Adds `tests/ui/missing/undeclared-generic-parameter.rs`.
Fixesrust-lang/rust#154165 and introduced by rust-lang/rust#152913
Simplify find_attr! for HirId usage
Add a `HasAttrs<'tcx, Tcx>` trait to `rustc_hir` that allows `find_attr!` to accept `DefId`, `LocalDefId`, `OwnerId`, and `HirId` directly, instead of requiring callers to manually fetch the attribute slice first.
Before:
`find_attr!(tcx.hir_attrs(hir_id), SomeAttr)`
After:
`find_attr!(tcx, hir_id, SomeAttr)`
The trait is defined in `rustc_hir` with a generic `Tcx` parameter to avoid a dependency cycle (`rustc_hir` cannot depend on `rustc_middle`). The four concrete impls for `TyCtxt` are in `rustc_middle`.
Fixes https://github.com/rust-lang/rust/issues/153103
Unknown -> Unsupported compression algorithm
Both zstd and zlib are *known* compression algorithms, they just may not be supported by the backend. We shouldn't mislead users into e.g. thinking they made a typo.
cc https://github.com/rust-lang/rust/issues/120953
Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/578893542) for more context. Discussed a bit in https://github.com/rust-lang/rust/pull/153769#discussion_r2934399038 too.
This renames `target.abi` to `target.cfg_abi` to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. `target.abi` does not control that calling convention, it just *sometimes* informs the user about that calling convention (and also about other aspects of the ABI).
Also turn llvm_abiname into an enum to make it more natural to match on.
Cc @workingjubilee @madsmtm
Improve inline assembly error messages
by
- using `DiagSymbolList` to get nicely formatted lists
- mentioning the `modifier` when an invalid modifier is used. This is useful in case the span cannot be resolved (which I ran into).
diagnostics: avoid ICE in confusable_method_name for associated functions
Avoid unconditionally slicing `inputs()[1..]`, which assumes a `self` parameter. Use `is_method()` to conditionally skip the receiver, preventing out-of-bounds access and fixing suggestions for associated functions.
On E0277 tweak help when single type impls traits
When encountering an unmet predicate, when we point at the trait impls that do exist, if they are all for the same self type, tweak the wording to make it less verbose.
[BPF] add target feature allows-misaligned-mem-access
This PR adds the allows-misaligned-mem-access target feature to the BPF target. The feature can enable misaligned memory access support in the LLVM backend, aligning Rust’s BPF target behavior with the corresponding LLVM update introduced in [llvm/llvm-project#167013](https://github.com/llvm/llvm-project/pull/167013) (included in LLVM 22).
This effectively reverses <https://github.com/rust-lang/rust/commit/4284edc>.
At that time, I thought GetQueryVTable might be useful for other kinds of
static lookup in the future, but after various other simplifications and
cleanups that now seems less likely, and this style is more consistent with
other vtable-related functions.
The different parts of this function used to be split across different crates,
but nowadays they are both in `rustc_query_impl`, so they can be combined.
This commit also hoists the vtable lookup to a closure in
`make_dep_kind_vtable_for_query`, to reduce the amount of code that deals with
`GetQueryVTable`, and to make the inner function more consistent with other
functions in `execution`.
In the serial compiler, we should never be trying to force a query node that
has a cached value, because we would have already marked the node red or green
when putting its value in cache.
In the parallel compiler, we immediately re-check the cache while holding the
state shard lock anyway, and trying to avoid that lock doesn't seem worthwhile.
Jacob Pratt