Inline and simplify some code for saving incremental data to disk
Main changes:
- Inline `encode_query_cache` and `TyCtxt::serialize_query_result_cache`
- Pull value promotion out of `OnDiskCache::drop_serialized_data`
- Panic if `on_disk_cache` is None in an incremental-only path
Replace the `try_mark_green` hook with direct calls to `tcx.dep_graph`
All of the existing call sites are directly touching `tcx.dep_graph` anyway, so the extra layer of indirection provides no real benefit.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
Remove the `rustc_data_structures::assert_matches!` re-exports
- https://github.com/rust-lang/rust/pull/151359
- https://github.com/rust-lang/rust/pull/153462
---
Now that the bootstrap stage0 compiler has been bumped to 1.95, we can remove these temporary re-exports from `rustc_data_structures`, and once again import the `assert_matches!` macros directly from std.
Currently we use a mix of `C::Key` and `&C::Key` parameters. The former
is more common and a bit nicer, so convert some of the latter. This
results in less converting between the two types, and fewer sigils.
Main changes:
- Inline `encode_query_cache` and `TyCtxt::serialize_query_result_cache`
- Pull value promotion out of `OnDiskCache::drop_serialized_data`
- Panic if `on_disk_cache` is None in an incremental-only path
Overhaul `ensure_ok`
The interaction of `ensure_ok` and the `return_result_from_ensure_ok` query modifier is weird and hacky. This PR cleans it up. Details in the individual commits.
r? @Zalathar
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#153202 ([win] Fix truncated unwinds for Arm64 Windows)
- rust-lang/rust#153437 (coretest in miri: fix using unstable libtest features)
- rust-lang/rust#153446 (Always use the ThinLTO pipeline for pre-link optimizations)
- rust-lang/rust#153548 (add test for closure precedence in `TokenStream`s)
Always use the ThinLTO pipeline for pre-link optimizations
When using cargo this was already effectively done for all dependencies as cargo passes -Clinker-plugin-lto without -Clto=fat/thin. -Clinker-plugin-lto assumes that ThinLTO will be used. The ThinLTO pre-link pipeline is faster than the fat LTO one. And according to the benchmarks in [^1] there is barely any runtime performance difference between executables that used fat LTO with the fat vs ThinLTO pre-link pipeline.
This also helps avoid having yet another code path if we want to support Unified LTO (that is a single bitcode file that supports being used for both fat LTO and ThinLTO when using linker plugin LTO, we already support it when rustc does LTO as ThinLTO bitcode is enough of a superset of fat LTO bitcode that it happens to work by accident if you don't explicitly have a check preventing mixing of them for the current set of LTO features that rustc exposes.) I'm currently still investigating if rustc would benefit from Unified LTO and how exactly to integrate it.
[^1]: https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774
[win] Fix truncated unwinds for Arm64 Windows
Panic backtraces on ARM64 Windows are truncated because Rust's LLVM configuration sets `NoTrapAfterNoreturn = true`, which suppresses the generation of `brk #0x1` (trap) instructions after calls to `noreturn` functions. Without this trap instruction, the return address from a `noreturn` call points past the end of the calling function into an unrelated function, causing `RtlLookupFunctionEntry` to return the wrong unwind information, which terminates the stack walk prematurely.
In general, `NoTrapAfterNoreturn = true` is recommended against for Windows, since we have seen security vulnerabilities in the past where an attacker has managed to return from a noreturn function, or the function wasn't actually noereturn, resulting in executing whatever was after the call.
This change disables setting `NoTrapAfterNoreturn = true` for Windows.
Fixesrust-lang/rust#140489
Don't use incremental disk-cache for query `predicates_of`
The `predicates_of` query is a relatively modest wrapper around a few underlying queries that are themselves cached to disk. Removing the additional layer of disk caching appears to be a significant perf win.
This query also appears to be the only query that uses a crate-local `cache_on_disk_if` condition, without also using the `separate_provide_extern` modifier.
- Discovered via https://github.com/rust-lang/rust/pull/153487#discussion_r2895304051
`ensure_ok` provides a special, more efficient way of calling a query
when its return value isn't needed. But there is a complication: if the
query is marked with the `return_result_from_ensure_ok` modifier, then
it will return `Result<(), ErrorGuaranteed`. This is clunky and feels
tacked on. It's annoying to have to add a modifier to a query to declare
information present in its return type, and it's confusing that queries
called via `ensure_ok` have different return types depending on the
modifier.
This commit:
- Eliminates the `return_result_from_ensure_ok` modifier. The proc macro
now looks at the return type and detects if it matches `Result<_,
ErrorGuarantee>`. If so, it adds the modifier
`returns_error_guaranteed`. (Aside: We need better terminology to
distinguish modifiers written by the user in a `query` declaration
(e.g. `cycle_delayed_bug`) from modifiers added by the proc macro
(e.g. `cycle_error_handling`.))
- Introduces `ensure_result`, which replaces the use of `ensure_ok` for
queries that return `Result<_, ErrorGuarantee>`. As a result,
`ensure_ok` can now only be used for the "ignore the return value"
case.
Gate #![reexport_test_harness_main] properly
Address the FIXME
Removed from `issue-43106-gating-of-builtin-attrs.rs` since that is for stable attributes only.
This would be a breaking change, search of github shows it is mostly but not always used with `#![test_runner]` which is already gated correctly.
Details:
https://github.com/rust-lang/rust/issues/50297
Feel free to close this issue if you think it is not worth addressing the FIXME...
Replace Box<[TraitCandidate]> with &'hir [TraitCandidate<'hir>]
This PR allocates trait candidates on HIR arena and replaces `remove` with `get` in `ResolverAstLowering`. First step for rust-lang/rust#153489.
r? @petrochenkov
Get rid of `QueryVTable::call_query_method_fn`
Calling the query method to promote a value is equivalent to doing a cache lookup and then calling `execute_query_fn`, so we can just do that manually instead.
There are two “functional” differences here: If a cache hit occurs, we don't record the hit for self-profiling, and we don't register a read of the dep node. In the context of promotion, which touches *all* eligible cache entries just before writing the memory-cached values to disk, those two steps should be unnecessary overhead anyway.
r? nnethercote (or compiler)
Two places where `ensure_ok` can be used but currently isn't. (These
queries are marked with `return_result_from_ensure_ok`, which means that
`ensure_ok` returns `Result<(), ErrorGuaranteed>`.) This is potentially
a perf win, because `ensure_ok` query calls can be faster.
`query_get_at`, `query_ensure`, and `query_ensure_error_guarantee` are
very similar functions, but they all use different control flow styles
which obscures the similarities. This commit rewrites them to all use
a `match`.
This query is a relatively modest wrapper around a few underlying queries that
are themselves cached to disk. Removing the additional layer of disk caching
appears to be a significant perf win.
This query also appears to be the only query that uses a crate-local
`cache_on_disk_if` condition, without also using the `separate_provide_extern`
modifier.
Clean up the eager formatting API
For https://github.com/rust-lang/rust/issues/151366#event-22181360642
Previously eager formatting worked by throwing the arguments into a diag, formatting, then removing the args again. This is ugly so instead we now just do the formatting completely separately.
This PR has nice commits, so I recommend reviewing commit by commit.
r? @GuillaumeGomez
Fallback to fat LTO for -Clto=thin in cg_gcc
Fallback to no LTO doesn't work in practice as Cargo asks rustc to produce LTO-only rlibs with -Clinker-plugin-lto without providing any indication if they will be used for thin or fat LTO, so we can't disable -Clinker-plugin-lto for ThinLTO when using cg_gcc.
r? @antoyo
Preserve parentheses around `Fn` trait bounds in pretty printer
The AST pretty printer was dropping parentheses around `Fn` trait bounds in `dyn`/`impl` types when additional `+` bounds were present. For example:
dyn (FnMut(&mut T) -> &mut dyn ResourceLimiter) + Send + Sync
was pretty-printed as:
dyn FnMut(&mut T) -> &mut dyn ResourceLimiter + Send + Sync
Without parens, `+ Send + Sync` binds to the inner `dyn ResourceLimiter` instead of the outer type, producing invalid Rust.
The parser already tracks parentheses via `PolyTraitRef.parens`, but `print_poly_trait_ref` never checked this field. This adds `popen()` and `pclose()` calls when `parens == Parens::Yes`.
Cleanup unused diagnostic emission methods
Part of https://github.com/rust-lang/rust/issues/153099.
To remove `lint_level`, we need to remove all functions calling it. One of them is `TyCtxt::node_span_lint`, so removing it.
r? @JonathanBrouwer
refactor: move `check_align` to `parse_alignment`
Part of rust-lang/rust#153101
r? @JonathanBrouwer
PS: jonathan i'm not sure about what to do with `check_align` now
Suppress invalid suggestions in destructuring assignment
Fixesrust-lang/rust#152694
When destructuring assignment hits a type with `Drop`, the compiler was emitting two broken suggestions: `ref *&mut String::new()` (invalid syntax) and `.clone()` on a temporary (useless).
Root cause: the suggestion logic didn't know these bindings were synthetic from assign desugaring. The fix reuses the existing `AssignDesugar` detection in `BindingFinder` to collect those spans and skip both suggestions.
Do not emit ConstEvaluatable goals if type-const
Fixesrust-lang/rust#151631, fixesrust-lang/rust#151477
r? @fmease
I'd recommend reviewing commit-by-commit, the diff is less-readable to address a cyclic issue.
Fix ICE in `offset_of!` error recovery
Fixesrust-lang/rust#153236.
`offset_of!` was changed in rust-lang/rust#148151 to lower through THIR as a sum of calls to the `offset_of` intrinsic. In the error-recovery case, when no valid field indices are recorded, that lowering synthesized `0` as a `u32` even though the overall `offset_of!` expression has type `usize`.
On 64-bit targets, const-eval then tried to write a 4-byte immediate into an 8-byte destination, which caused the ICE.
libcore float tests: replace macro shadowing by const-compatible macro
This lets us avoid https://github.com/rust-lang/rust/issues/153478.
However this means we generate 3 function items per assertion -- or rather, 3*8, since every assertion gets duplicated 8 times (4 float types, each in a const and a non-const variant). That's a lot; is it enough to be concerned about?
coretest already takes forever to build. In a quick test, build time increased from 29.8s to 30.8s, but that may also entirely be noise.
r? @tgross35
Box in `ValTreeKind::Branch(Box<[I::Const]>)` changed to `List`
This is related to trait system refactoring. It fixes the FIXME in `ValTreeKind`
```
// FIXME(mgca): Use a `List` here instead of a boxed slice
Branch(Box<[I::Const]>),
```
It introduces `Interner::Consts`, changes `Branch(Box<[I::Const]>)` to `Branch(I::Consts)`, and updates all relevant places.
r? lcnr
Fix incorrect trailing comma suggested in no_accessible_fields
Fixesrust-lang/rust#149787
r? @estebank
I think add new field for AST for it is too heavy change for this issue, here is a trivial fix with source_map, seems enough for it.
Fallback to no LTO doesn't work in practice as Cargo asks rustc to
produce LTO-only rlibs with -Clinker-plugin-lto without providing any
indication if they will be used for thin or fat LTO, so we can't disable
-Clinker-plugin-lto for ThinLTO when using cg_gcc.
Jonathan Brouwer