Streamline `CachingSourceMapView`
`CachingSourceMapView` is home to some pretty ugly, low-level, repetitive code. We can do better. Details in individual commits.
r? @JonathanBrouwer
Don't use disk-cache for query `def_kind`
From what I can tell, the `def_kind` query has no local provider, and is always given its value via query feeding, usually from `TyCtxt::create_def`.
If that's the case, there should never be any opportunity for a previous value to be loaded from disk-cache, so serializing the current-session values is a waste of time.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#152935 (c-variadic: error when we can't guarantee that the backend does the right thing)
- rust-lang/rust#153207 (std::net: clamp linger timeout value to prevent silent truncation.)
- rust-lang/rust#154592 (Fix `mismatched_lifetime_syntaxes` suggestions for hidden path lifetimes)
- rust-lang/rust#154643 (fix pin docs)
- rust-lang/rust#154648 (Clarify `ty::List`)
From what I can tell, the `def_kind` query has no local provider, and is always
given its value via query feeding, usually from `TyCtxt::create_def`.
If that's the case, there should never be any opportunity for a previous value
to be loaded from disk-cache, so serializing the current-session values is a
waste of time.
specifically this emits an error when
- a custom target is used
- `RiscV32 if self.llvm_abiname == "ilp32e"` this abi is used for 32-bit
embedded targets, and clang/llvm document that the ABI may change in
the future.
- Merge the `List` and `ListWithCachedTypeInfo` impls by referring to
the shared underlying type, `RawList`. This required increasing the
visibility of `RawList`.
- Explain why a separate impl is needed for `RawList`.
- Remove an incorrect FIXME comment. Fat reference types will always
need a separate impl. (To be sure, one could use `T: ?Sized` to merge
the impls for `&T` and `&[T]` and it would compile but it would behave
incorrectly because `&T` needs one word of storage and `&[T]` needs
two words of storage. I tried it and it did not go well.)
- Add some explanatory comments.
- Rename `OpaqueListContents` as `ExternTy`. I've always found both the
"opaque" and "contents" parts of this name to be confusing. Calling it
`ExternTy` makes it clear that all that matters is it's an extern
type.
`CachingSourceMapView` caches information about three recent code
positions, to avoid expensive `SourceMap` lookups. The code to do this
is pretty low-level and grotty.
This commit changes it to cache information about a single code
position.
- This is much simpler, with no need to maintain entry time stamps or
file indices. It's 120 fewer lines of code overall.
- It's also faster. The cache hit rate is only marginally lower, and
scanning a single entry is faster than scanning three entries in the
cache miss case (which is still moderately common).
The commit also renames the `lines` field as `line_bounds`, which makes
it clearer that it's a range.
Currently the `cache_entry_index` uses -1 to indicate failure. But this
is Rust, not C! So this commit uses `Option`, making it impossible to
forget to check for failure, and avoiding many `as usize` casts.
Use `Hcx`/`hcx` consistently for `StableHashingContext`.
The `HashStable` and `ToStableHashKey` traits both have a type parameter that is sometimes called `CTX` and sometimes called `HCX`. (In practice this type parameter is always instantiated as `StableHashingContext`.) Similarly, variables with these types are sometimes called `ctx` and sometimes called `hcx`. This inconsistency has bugged me for some time.
The `HCX`/`hcx` form is more informative (the `H`/`h` indicates what type of context it is) and it matches other cases like `tcx`, `dcx`, `icx`.
Also, RFC 430 says that type parameters should have names that are "concise UpperCamelCase, usually single uppercase letter: T". In this case `H` feels insufficient, and `Hcx` feels better.
Therefore, this commit changes the code to use `Hcx`/`hcx` everywhere.
r? @petrochenkov
add rustc option -Zpacked-stack
this enables `-Zpacked-stack` just as `-mpacked-stack` in clang and gcc. packed-stack is needed on s390x for kernel development.
For reference: rust-lang/rust#151154 and rust-lang/rust#150766
look at @uweigand s post for full explanation of what this does. Here a wrap-up:
https://github.com/rust-lang/rust/pull/150766#issuecomment-3729074303
> [...]
> packed-stack [...] modifies how the compiler-generated function prolog/epilog code makes use of the 160 byte register save area provided by a caller to the callee [...] this variant is not actually incompatible with the ABI - packed-stack and regular functions can freely call each other without ABI issues.
> [...]
> combination of -mpacked-stack and -mbackchain [...] the location in the stack frame where the backchain link ought to be stored is not available. [...] is not supported at all with the default ABI
> [...]
> However, in the special case of also using soft-float, our (implied) soft-float ABI provides a different location for the backchain that is compatible with -mpacked-stack, so that combination should be supported
> [...]
Simplify the `cache_on_disk_if` modifier to just `cache_on_disk`
Thanks to https://github.com/rust-lang/rust/pull/154304, there is now only one remaining query with a non-trivial cache-on-disk condition (`check_liveness`). But prior experiments at https://github.com/rust-lang/rust/pull/153441#issuecomment-4009037104 indicate that `check_liveness` can also be made non-disk-caching with little or no measurable effect.
This PR takes advantage of those facts to replace the `cache_on_disk_if` modifier with a simpler `cache_on_disk` modifier:
- When combined with `separate_provide_extern`, only values for “local” keys are cached to disk.
- For any other query with `cache_on_disk`, values are cached to disk unconditionally.
r? nnethercote (or compiler)
refactor: remove `Adjust::ReborrowPin`
Followed by rust-lang/rust#149130, this PR removes `Adjust::ReborrowPin` and use an `Adjust::Deref(DerefAdjustKind::Pin)` followed by an `Adjust::Borrow(AutoBorrow::Pin)` instead.
Take first task group for further execution
Continuing from https://github.com/rust-lang/rust/pull/153768#discussion_r2938828363.
I thought that storing a first group of tasks for immediate execution instead of pushing and immediately poping it from rayon's local task queue in par_slice would avoid overwhelming work stealing potentially blocking the original thread. So I've implemented this change.
8 threads benchmarks:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>baseline~~9</b></th><td colspan="2"><b>new~take-first-group~1</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.1110s</td><td align="right">0.1086s</td><td align="right">💚 -2.13%</td></tr><tr><td>🟣 <b>hyper</b>:check:initial</td><td align="right">0.1314s</td><td align="right">0.1298s</td><td align="right">💚 -1.23%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.0771s</td><td align="right">0.0755s</td><td align="right">💚 -2.14%</td></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">0.3787s</td><td align="right">0.3757s</td><td align="right"> -0.80%</td></tr><tr><td>🟣 <b>clap</b>:check:initial</td><td align="right">0.4680s</td><td align="right">0.4564s</td><td align="right">💚 -2.48%</td></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.2337s</td><td align="right">0.2301s</td><td align="right">💚 -1.52%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">0.4321s</td><td align="right">0.4265s</td><td align="right">💚 -1.31%</td></tr><tr><td>🟣 <b>syn</b>:check:initial</td><td align="right">0.5586s</td><td align="right">0.5401s</td><td align="right">💚 -3.31%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.3434s</td><td align="right">0.3429s</td><td align="right"> -0.14%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.2755s</td><td align="right">0.2661s</td><td align="right">💚 -3.40%</td></tr><tr><td>🟣 <b>regex</b>:check:initial</td><td align="right">0.3350s</td><td align="right">0.3347s</td><td align="right"> -0.11%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.1851s</td><td align="right">0.1832s</td><td align="right">💚 -1.01%</td></tr><tr><td>Total</td><td align="right">3.5296s</td><td align="right">3.4695s</td><td align="right">💚 -1.70%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9837s</td><td align="right">💚 -1.63%</td></tr></table>
The `HashStable` and `ToStableHashKey` traits both have a type parameter
that is sometimes called `CTX` and sometimes called `HCX`. (In practice
this type parameter is always instantiated as `StableHashingContext`.)
Similarly, variables with these types are sometimes called `ctx` and
sometimes called `hcx`. This inconsistency has bugged me for some time.
The `HCX`/`hcx` form is more informative (the `H`/`h` indicates what
type of context it is) and it matches other cases like `tcx`, `dcx`,
`icx`.
Also, RFC 430 says that type parameters should have names that are
"concise UpperCamelCase, usually single uppercase letter: T". In this
case `H` feels insufficient, and `Hcx` feels better.
Therefore, this commit changes the code to use `Hcx`/`hcx` everywhere.
Skip suggestions pointing to macro def for assert_eq
Fixesrust-lang/rust#146204
It's better to suggest:
```console
help: consider borrowing here
--> src/main.rs:3:16
|
3| assert_ne!(&buf, b"----");
| +
```
but i don't want to give a too heuristic but not general enough fix, let suppress them.
Fix regression when dealing with generics/values with unresolved inference
Follow up for rust-lang/rust#151703, fixing regression caused in rollup rust-lang/rust#152825
Forgot to handle generics & unresolved inference variables (as in `get_safe_transmute_error_and_reason`) in my previous PR. This followup checks for them before trying to normalize.
I am not completely sure its right approach to have this check cloned but as `select_transmute_obligation_for_reporting` fn just chooses obligation and doesn't actually return an error, this check shouldn't be removed from `get_safe_transmute_error_and_reasnon`. If there is any better solution, let me kmow.
Fixes: rust-lang/rust#153755
r? @jdonszelmann
Avoid ICE when param-env normalization leaves unresolved inference variables
Fixesrust-lang/rust#153354
Because the impl is already ill-formed, those variables are not fully constrained, so zfully_resolve` fails. We previously treated that as an immediate compiler bug with `span_bug!`, which caused an ICE on invalid input.
this enables packed-stack just as -mpacked-stack in clang and gcc.
packed-stack is needed on s390x for kernel development.
Co-authored-by: Ralf Jung <post@ralfj.de>
Queries with both `cache_on_disk` and `separate_provide_extern` will only
disk-cache values for local keys.
Other queries with `cache_on_disk` will disk-cache all values unconditionally.
stabilizes `core::range::Range`
stabilizes `core::range::RangeIter`
stabilizes `std::range` which was missed in prior PRs
Updates docs to reflect stabilization (removed "experimental")
`RangeIter::remainder` is excluded from stabilization
This is the only remaining query with a non-trivial `cache_on_disk_if`
condition, but previous perf experiments indicate that it can be removed
entirely, with little or no measurable effect.
Waffle Lapkin