Rollup of 16 pull requests #139203
Closed
Rollup of 16 pull requests #139203
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Mark Rousskov <[email protected]> Co-authored-by: alexey semenyuk <[email protected]>
We also have to remove the LLVM argument in cast-target-abi.rs for LLVM 21. I'm not really sure what the best approach here is since that test already uses revisions. We could also fork the test into a copy for LLVM 19-20 and another for LLVM 21, but what I did for now was drop the lint-abort-on-error flag to LLVM figuring that some coverage was better than none, but I'm happy to change this if that was a bad direction. The above also applies for ffi-out-of-bounds-loads.rs. r? dianqk @rustbot label llvm-main
This test is intended to demonstrate that a particular macro-argument span doesn't get lost during span-refinement, but it turns out that span-extraction currently doesn't yield any MIR spans for this position. This patch therefore tweaks the test to add a function call in that position, so that it still remains relevant to span refinement.
This is a way to shrink call spans that doesn't involve mixing different spans, and avoids overlap with argument spans. This patch also removes some low-value comments that were causing rustfmt to ignore the match arms.
…r, r=GuillaumeGomez rustdoc-json: Add test for #[automatically_derived] attribute ~~Will fail CI due to freestrings/jsonpath#91, but I wrote the test and don't want to forget it.~~ ~~We should look into fixing the freestrings impl, or moving to a different one, so we can test things like this. [Zulip Disussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/jsonpath-plus.20integration)~~ FIXED!!! By rust-lang#138763 r? `@ghost` `@rustbot` blocked
…e_iter, r=dtolnay Make slice iterator constructors unstably const See [tracking issue](rust-lang#137737) for justification.
remove `feature(inline_const_pat)` Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck. With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now: - we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types - we want the inline const pattern to participate in exhaustiveness checking - to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**. There are 4 possible ways to handle this: - stop typechecking inline const patterns together with their parent - causes inline const patterns to be different than inline const exprs - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1` - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn - inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck - difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing - do they carry their weight if they are now just equivalent to using an if-guard - delay exhaustiveness checking until after borrowck - should be possible in theory, but is a quite involved change and may have some unexpected challenges - remove this feature for now I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out. `const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920. r? types cc `@rust-lang/types` `@rust-lang/lang` rust-lang#76001
Fix UWP reparse point check Fixes rust-lang#138921
replace extra_filename with strict version hash in metrics file names Should resolve the potential issue of overwriting metrics from the same crate when compiled with different features or flags. r? `@estebank`
Add release notes for 1.86.0 Closes rust-lang#138795 (the draft) cc `@rust-lang/release` `@rustbot` ping relnotes-interest-group
increment depth of nested obligations properly fixes the root cause of rust-lang#109268. While we didn't get hangs here before, I ended up encountering its root cause again with rust-lang#138785. r? types
…it-with-actual-value, r=onur-ozkan replace commit placeholder in vendor status with actual commit closes: rust-lang#120499
coverage: Avoid splitting spans during span extraction/refinement This PR removes or simplifies some of the steps involved in extracting coverage-relevant spans from MIR, and preparing them for use in coverage instrumentation metadata. A common theme is that we now try harder to avoid modifying or combining spans in non-trivial ways, because those modifications present the most risk for weird behaviour or ICEs. The main changes are: - When extracting spans from MIR call terminators, try to restrict them to just the function name. - Instead of splitting spans around “holes”, just discard any span that overlaps with a hole. - Instead of splitting macro-invocation spans into two parts, truncate them to just the macro name and subsequent `!`. --- This results in a lot of tiny changes to the spans that end up in coverage metadata, and a few changes to coverage reports. Judging by test snapshots, these changes appear to be quite minor in practice.
…-check-optimization, r=fee1-dead Add tests for slice bounds check optimization Closes rust-lang#134466
PassWrapper: adapt for llvm/llvm-project@94122d58fc77079a291a3d008914… …006cb509d9db We also have to remove the LLVM argument in cast-target-abi.rs for LLVM 21. I'm not really sure what the best approach here is since that test already uses revisions. We could also fork the test into a copy for LLVM 19-20 and another for LLVM 21, but what I did for now was drop the lint-abort-on-error flag to LLVM figuring that some coverage was better than none, but I'm happy to change this if that was a bad direction. r? dianqk `@rustbot` label llvm-main
…r=eholk Feed HIR for by-move coroutine body def, since the inliner tries to read its attrs See the comments in the test. I'm surprised that nobody found this[^1] (edit: nvm haha), but you have to go out of your way to construct the by-move body and then inline it w/ a poll call, so I guess the inliner just never really gets into this situation before. Fixes rust-lang#134335 r? oli-obk [^1]: Well, `@eholk` found this when working on the `iter! {}` macro, since it more dramatically affects those.
rustbot
added
A-rustdoc-json
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
feature(inline_const_pat)#138492 (removefeature(inline_const_pat))unused_attributesfor#[inline]on exported functions #138842 (Emitunused_attributesfor#[inline]on exported functions)DefPathData#139153 (Encode synthetic by-move coroutine body with a differentDefPathData)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup