Use thread local dep graph encoding
This adds thread local encoding of dep graph nodes. Each thread has a `MemEncoder` that gets flushed to the global `FileEncoder` when it exceeds 64 kB. Each thread also has a local cache of dep indices. This means there can now be empty gaps in `SerializedDepGraph`.
Indices are marked green and also allocated by the new atomic operation `DepNodeColorMap::try_mark_green` as the encoder lock is removed.
fix typo in autorefs lint doc example
The documentation is talking about other way using only raw pointers, but the example was use `std::slice::from_raw_parts_mut` which also create a reference. `std::ptr::slice_from_raw_parts_mut` should be used instead, and it also highlights the benefit of raw pointer manipulation compared to dereference, as the function doesn't need to be unsafe anymore.
Moreover, [`unsafe_op_in_unsafe_fn`](https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html) warning has been enabled since Edition 2024, so I've updated the examples to use unsafe blocks.
By using `@` patterns more.
Also, use `Symbol` more in a couple of errors to avoid some unnecessary
conversions to strings. This even removes a lifetime.
rust-analyzer doesn't construct `DerefPattern(_)` constructors, so these
shouldn't crash. It looks like this is how slice patterns are
implemented too.
Without adding proper support for mixed exhaustiveness, mixing deref
patterns with normal constructors would either violate
`ConstructorSet::split`'s invariant 4 or 7. We'd either be ignoring rows
with normal constructors or we'd have problems in unspecialization from
non-disjoint constructors. Checking mixed exhaustivenss similarly to how
unions are currently checked should work, but the diagnostics for unions
are confusing. Since mixing deref patterns with normal constructors is
pretty niche (currently it only makes sense for `Cow`), emitting an
error lets us avoid committing to supporting mixed exhaustiveness
without a good answer for the diagnostics.
This does not yet handle the case of mixed deref patterns with normal
constructors; it'll ICE in `Constructor::is_covered_by`. That'll be
fixed in a later commit.
collect all Fuchsia bindings into the `fuchsia` module
The Fuchsia bindings are currently spread out across multiple modules in `sys/pal/unix` leading to unnecessary duplication. This PR moves all of these definitions into `sys::pal::unix::fuchsia` and additionally:
* deduplicates the definitions
* makes the error names consistent
* marks `zx_thread_self` and `zx_clock_get_monotonic` as safe extern functions
* removes unused items (there's no need to maintain these bindings if we're not going to use them)
* removes the documentation for the definitions (contributors should always consult the platform documentation, duplicating that here is just an extra maintenance burden)
`@rustbot` ping fuchsia
support duplicate entries in the opaque_type_storage
Necessary for the new solver as we may unify keys when eagerly resolving for canonical queries. See the relevant comment when instantiating query responses:
```rust
// We eagerly resolve inference variables when computing the query response.
// This can cause previously distinct opaque type keys to now be structurally equal.
//
// To handle this, we store any duplicate entries in a separate list to check them
// at the end of typeck/borrowck. We could alternatively eagerly equate the hidden
// types here. However, doing so is difficult as it may result in nested goals and
// any errors may make it harder to track the control flow for diagnostics.
if let Some(prev) = prev {
self.delegate.add_duplicate_opaque_type(key, prev, self.origin_span);
}
```
This will be far more relevant with #140497.
r? `@compiler-errors`
Comment on `Rc` abort-guard strategy without naming unrelated fn
`wrapped_add` is used, not `checked_add`, so avoid mentioning specific fn calls that may vary slightly based on "whatever produces the best code" and focus on things that will remain constant into the future.
Move `in_external_macro` to `SyntaxContext`
There are a few places in clippy where spans are passed solely to use the context, but we can't pass just the context around because of this function.
The documentation is talking about other way using only raw pointers, but the example was use `std::slice::from_raw_parts_mut` which also create a reference. `std::ptr::slice_from_raw_parts_mut` should be used instead, and it also highlights the benefit of raw pointer manipulation compared to dereference, as the function doesn't need to be unsafe anymore.
Moreover, [`unsafe_op_in_unsafe_fn`](https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html) warning has been enabled since Edition 2024, so I've updated the examples to use unsafe blocks.
Stabilize proc_macro::Span::{file, local_file}.
Stabilizes this part of https://github.com/rust-lang/rust/issues/54725:
```rust
impl Span {
pub fn file(&self) -> String; // Mapped/artificial file name, for display purposes.
pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on the local file system.
}
```
See also the naming discussion in https://github.com/rust-lang/rust/issues/139903
Rollup of 4 pull requests
Successful merges:
- #136183 (Update iterator.rs to use arrays by value)
- #139966 (coverage: Only merge adjacent coverage spans)
- #140692 (Rename `graph::implementation::Graph` to `LinkedGraph`)
- #140703 (Handle PR not found in post-merge workflow)
r? `@ghost`
`@rustbot` modify labels: rollup
Rename `graph::implementation::Graph` to `LinkedGraph`
One of the more confusing parts of the `rustc_data_structures::graph` module is this mysteriously-named “Graph” type, which turns out to be an older standalone graph implementation that predates the traits used by the rest of the graph module.
This graph type is still used in a couple of places (for reporting certain lifetime errors, and by certain debugging/test-only checks of the query dependency graph), but hasn't had much attention in years.
This PR renames that old graph type from `implementation::Graph` to `linked_graph::LinkedGraph` to give it a more distinct identity (and make existing uses easier to find), and adds some notes to gently discourage any further use in new code.
No functional change.
coverage: Only merge adjacent coverage spans
For a long time, coverage instrumentation has automatically “merged” spans with the same control-flow into a smaller number of larger spans, even when the spans being merged are not overlapping or adjacent. This causes any source text between the original spans to be included in the merged span, which is then associated with an execution count when shown in coverage reports.
That approach causes a number of problems:
- The intervening source text can contain all sorts of things that shouldn't really be marked as executable code (e.g. nested items, parts of macro invocations, long comments). In some cases we have complicated workarounds (e.g. bucketing to avoid merging spans across nested items), but in other cases there isn't much we can do.
- Merging can have aesthetically weird effects, such as including unbalanced parentheses, because the merging process doesn't really understand what it's doing at a source code level.
- It generally leads to an accumulation of piled-on heuristics and special cases that give decent-looking results, but are fiendishly difficult to modify or replace.
Therefore, this PR aims to abolish the merging of non-adjacent coverage spans.
The big tradeoff here is that the resulting coverage metadata (embedded in the instrumented binary) tends to become larger, because the overall number of distinct spans has increased. That's unfortunate, but I see it as the inevitable cost of cleaning up the messes and inaccuracies that were caused by the old approach. And the resulting spans do tend to be more accurate to the program's actual control-flow.
---
The `.coverage` snapshot changes give an indication of how this PR will affect user-visible coverage reports. In many cases the changes to reporting are minor or even nonexistent, despite substantial changes to the metadata (as indicated by `.cov-map` snapshots).
---
try-job: aarch64-gnu
Rollup of 4 pull requests
Successful merges:
- #140135 (Unify sidebar buttons to use the same image)
- #140632 (add a test for issue rust-lang/rust#81317)
- #140658 (`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching)
- #140681 (Don't ignore compiler stderr in `lib-defaults.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
