| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
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.
|
|
Rollup of 4 pull requests
Successful merges:
- #139518 (Stabilize precise capture syntax in style guide)
- #140398 (Fix backtrace for cygwin)
- #140719 (fix typo in autorefs lint doc example)
- #140724 (Update `compiler-builtins` to 0.1.158)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update `compiler-builtins` to 0.1.158
Includes the following changes:
* Require `target_has_atomic = "ptr"` for runtime feature detection [1]
[1]: https://github.com/rust-lang/compiler-builtins/pull/909
|
|
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.
|
|
Fix backtrace for cygwin
Closes #140304
Depends on:
- [x] https://github.com/rust-lang/backtrace-rs/pull/704
This PR could not be merged until the above PR is merged. I'll update the submodule then.
EDIT: submodule updated.
|
|
Stabilize precise capture syntax in style guide
Closes #138527
r? `@jieyouxu`
|
|
Remove duplicate impl of string unescape from parse_format
r? `@nnethercote`
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #134273 (de-stabilize bench attribute)
- #139534 (Added support for `apxf` target feature)
- #140419 (Move `in_external_macro` to `SyntaxContext`)
- #140483 (Comment on `Rc` abort-guard strategy without naming unrelated fn)
- #140607 (support duplicate entries in the opaque_type_storage)
- #140656 (collect all Fuchsia bindings into the `fuchsia` module)
- #140668 (Implement `VecDeque::truncate_front()`)
- #140709 (rustdoc: remove unportable markdown lint and old parser)
- #140713 (Structurally resolve in `check_ref_cast` in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Structurally resolve in `check_ref_cast` in new solver
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/203
r? lcnr
|
|
rustdoc: remove unportable markdown lint and old parser
Follow up https://github.com/rust-lang/rust/pull/127127
|
|
Implement `VecDeque::truncate_front()`
Tracking issue: #140667
|
|
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.
|
|
r=workingjubilee
Added support for `apxf` target feature
|
|
de-stabilize bench attribute
This has been soft-unstable since forever (https://github.com/rust-lang/rust/pull/64066), and shown in future-compat reports since Rust 1.77 (https://github.com/rust-lang/rust/pull/116274).
The feature covering `bench` itself is tracked in https://github.com/rust-lang/rust/issues/50297, which has been closed despite still having active feature gates referencing it.
Cc `@rust-lang/libs-api`
|
|
Includes the following changes:
* Require `target_has_atomic = "ptr"` for runtime feature detection
[1]: https://github.com/rust-lang/compiler-builtins/pull/909
|
|
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
|
|
Update comment per review feedback
|
|
|
|
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
|
|
|
|
|
|
Follow up https://github.com/rust-lang/rust/pull/127127
|
|
Handle PR not found in post-merge workflow
Should hopefully fix errors like [these](https://github.com/rust-lang/rust/pull/140561#issuecomment-2854636223).
r? `@marcoieni`
|
|
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
|
|
Update iterator.rs to use arrays by value
Update examples to no longer avoid iterating arrays for #84513
|
|
|
|
|
|
|
|
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
|
|
Don't ignore compiler stderr in `lib-defaults.rs`
Closes #54222.
- Don't ignore compiler stderr.
- Document test intent.
- Move under `tests/ui/link-native-libs/` instead.
This was previously discussed on https://web.archive.org/web/20181028094402/https://botbot.me/mozilla/rust-tools/2017-02-21/?page=1.
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: aarch64-apple
try-job: x86_64-apple-1
|
|
`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching
This follows up on #140028. Together, they allow using string and byte string literal patterns to match on smart pointers when `deref_patterns` is enabled. In particular, string literals can now match on `String`, subsuming the functionality of the `string_deref_patterns` feature.
More generally, this works by letting literals peel references (and smart pointers) before matching, similar to most other patterns, providing an answer to #44849. Though it's only partially implemented at this point: this doesn't yet let named const patterns peel before matching. The peeling logic is general enough to support named consts, but the typing rules for named const patterns would need adjustments to feel consistent (e.g. arrays would need rules to be usable as slices, and `const STR: &'static str` wouldn't be able to match on a `String` unless a rule was added to let it be used where a `str` is expected, similar to what #140028 did for literals).
This also allows string and byte string patterns to match on mutable references, following up on https://github.com/rust-lang/rust/pull/140028#discussion_r2053927512. Rather than forward the mutability of the scrutinee to literal patterns, I've opted to peel `&mut`s from the scrutinee. From a design point of view, this makes the behavior consistent with what would be expected from deref coercions using the methodology in the next paragraph. From a diagnostics point of view, this avoids labeling string and byte string patterns as "mutable references", which I think could be confusing. See [`byte-string-type-errors.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-4a0dd9b164b67c706751f3c0b5762ddab08bcef05a91972beb0190c6c1cd3706) for how the diagnostics look.
At a high level, the peeling logic implemented here tries to mimic how deref coercions work for expressions: we peel references (and smart pointers) from the scrutinee until the pattern can match against it, and no more. This is primarily tested by [`const-pats-do-not-mislead-inference.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-19afc05b8aae9a30fe4a3a8c0bc2ab2c56b58755a45cdf5c12be0d5e83c4739d). To illustrate the connection, I wasn't sure if this made sense to include in the test file, but I've translated those tests to make sure they give the same inference results as deref coercions: [(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1869744cb9cdfed71a686990aadf9fe1). In each case, a reference to the scrutinee is coerced to have the type of the pattern (under a reference).
Tracking issue for deref patterns: #87121
r? `@oli-obk`
cc `@Nadrieril`
|
|
add a test for issue rust-lang/rust#81317
closes rust-lang/rust#81317
|
|
Unify sidebar buttons to use the same image
Part of https://github.com/rust-lang/rust/issues/139832.
The source sidebar looks like this with the new image:
You can test it [here](https://rustdoc.crud.net/imperio/sidebar-images/src/foo/foo.rs.html).
r? `@notriddle`
|
|
Update examples to no longer avoid iterating arrays for #84513
|
|
Because we no longer merge non-adjacent spans, there is no need to use buckets
to prevent merging across hole spans.
|
|
This also removes some manipulation of the function signature span that only
made sense in the context of merging non-adjacent spans.
|
|
Do not gather local all together at the beginning of typeck
r? lcnr
|
|
|
|
And also:
- Document test intent.
- Move under `link-native-libs/` instead.
|
|
Rollup of 12 pull requests
Successful merges:
- #139550 (Fix `-Zremap-path-scope` rmeta handling)
- #139764 (Consistent trait bounds for ExtractIf Debug impls)
- #139773 (Implement `Iterator::last` for `vec::IntoIter`)
- #140035 (Implement RFC 3503: frontmatters)
- #140251 (coverage-dump: Resolve global file IDs to filenames)
- #140393 (std: get rid of `sys_common::process`)
- #140532 (Fix RustAnalyzer discovery of rustc's `stable_mir` crate)
- #140598 (Steer docs to `utf8_chunks` and `Iterator::take`)
- #140634 (Use more accurate ELF flags on MIPS)
- #140673 (Clean rustdoc tests folder)
- #140678 (Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis)
- #140687 (Update mdbook to 0.4.49)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update mdbook to 0.4.49
This is a routine update to pull in some fixes and updates.
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0449
|
