core: respect precision in `ByteStr` `Display`
Fixesrust-lang/rust#153022.
`ByteStr`'s `Display` implementation didn't respect the precision parameter. Just like `Formatter::pad`, this is fixed by counting off the characters in the string and truncating after the requested length – with the added complication that the `ByteStr` needs to be divided into chunks first. By including a fast path that avoids counting the characters when no parameters were specified this should also fix the performance regressions caused by rust-lang/rust#152865.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152535 (std: use `OnceLock` for Xous environment variables)
- rust-lang/rust#152646 (Update `UnsafeUnpin` impls involving extern types.)
- rust-lang/rust#153559 (Inline and simplify some code for saving incremental data to disk)
- rust-lang/rust#151900 (num: Separate public API from internal implementations)
- rust-lang/rust#153520 (.mailmap: fix broken line with multiple emails)
- rust-lang/rust#153573 (rustdoc-json: fix incorrect documentation for VariantKind::Struct)
Failed merges:
- rust-lang/rust#153509 (Cleanup unused diagnostic emission methods - part 2)
rustdoc-json: fix incorrect documentation for VariantKind::Struct
Seems to have been copy-and-pasted from `Enum::variants`, but `VariantKind::Struct::fields` is for struct variant fields, not enum variants.
num: Separate public API from internal implementations
Currently we have a single `core::num` module that contains both thin wrapper API and higher-complexity numeric routines. Restructure this by moving implementation details to a new `imp` module.
This results in a more clean separation of what is actually user-facing compared to items that have a stability attribute because they are public for testing.
The first commit does the actual change then the second moves a portion back.
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
Update `UnsafeUnpin` impls involving extern types.
`UnsafeUnpin` tracking issue: https://github.com/rust-lang/rust/issues/125735
Relaxes from `T: ?Sized` (i.e. `T: MetaSized`) to `T: PointeeSized` for the `UnsafeUnpin` impls for pointers, references, and `PhantomData<T>`, and for the negative `UnsafeUnpin` impl for `UnsafePinned<T>`. (Compare to the impls for `Freeze` on lines 911-921.)
Both `UnsafeUnpin` and `extern type`s (the only way to have a `!MetaSized` type) are unstable, so this should have no effect on stable code.
Also updates the marker_impls macro docs to use PointeeSized bound, as most uses of the macro now do.
Concretely, this change means that the following types will newly implement `UnsafeUnpin`:
* pointers and references to `T` where `T` is an `extern type`
* `PhantomData<T>` where `T` is an extern type
* either of the above where `T` is a `struct` or tuple with `extern type` tail
Additionally, the negative `UnsafeUnpin` impl for `UnsafePinned<T>` is also relaxed to `T: PointeeSized` to align with the analogous negative `Freeze` impl for `UnsafeCell<T>`, even though both structs have `T: ?Sized` in their declaration (which probably should be relaxed, but that is a separate issue), so this part of the change doesn't actually *do* anything currently, but if `UnsafeCell` and `UnsafePinned` are later relaxed to `T: PointeeSized`, then the negative impl will apply to the newly possible instantiations. Also cc https://github.com/rust-lang/rust/issues/152645 that these impls compile at all.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#153464 (Use `&C::Key` less in queries.)
- rust-lang/rust#153553 (Remove the `rustc_data_structures::assert_matches!` re-exports)
- rust-lang/rust#153561 (Replace the `try_mark_green` hook with direct calls to `tcx.dep_graph`)
- rust-lang/rust#153564 (rendering interpreter OOM as OOM instead of ICE)
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.
Use `&C::Key` less in queries.
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.
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...
Bootstrap update
- Replace version placeholders with 1.95.0
- Bump stage0 to 1.95.0-beta.1
- Clear `STAGE0_MISSING_TARGETS`
- Update `cfg(bootstrap)`
- Reformat with the new stage0
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.
Jynn Nelson