-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 4 pull requests #133079
Rollup of 4 pull requests #133079
Conversation
They each have a single callsite, and the result is always unwrapped, so the `Option<Annotatable>` return type is misleading. Also, the comment at the `configure_annotatable` call site is wrong, talking about a result vector, so this commit also removes that.
Important: we know from the `parse_annotatable_with` call above the call site that only some of the `Annotatable` variants are possible. The remaining cases can be replaced with `unreachable!`.
There are two matches: one in a closure, and one vanilla one. They can be combined and simplified by putting them in a `try` block.
Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly. Tests the LLVM behaviour added in: llvm/llvm-project@1782810
…tures-apit, r=BoxyUwU Recurse into APITs in `impl_trait_overcaptures` We were previously not detecting cases where an RPIT was located in the return type of an async function, leading to underfiring of the `impl_trait_overcaptures`. This PR does this recursion properly now. cc rust-lang#132809
…otatable, r=petrochenkov Refactor `configure_annotatable` This PR streamlines `configure_annotatable` and nearby code considerably. r? `@petrochenkov`
…ag-merge, r=jieyouxu tests: Test pac-ret flag merging on clang with LTO Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly. try-job: aarch64-gnu-debug
…g_arg, r=compiler-errors Change Visitor::visit_precise_capturing_arg so it returns a Visitor::Result r? `@petrochenkov` related to rust-lang#128974
@bors r+ rollup=never p=4 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: ce40196577 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (917a50a): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 786.906s -> 788.599s (0.22%) |
Successful merges:
impl_trait_overcaptures
#132817 (Recurse into APITs inimpl_trait_overcaptures
)configure_annotatable
#133021 (Refactorconfigure_annotatable
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup