-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Rollup of 5 pull requests #151234
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 5 pull requests #151234
Conversation
…ocation on reexported item
While these test cases were inspired by issue 137467, they aren't directly related, and better fit into match-edge-cases_2.rs
…lds higher than 1
…crates-docs, r=jieyouxu Generate macro expansion for rust compiler crates docs Re-enable rust-lang#150022, which was disabled in rust-lang#149831 because some fixes hadn't been merged then. r? @jieyouxu
…=lolbinarycat Fix deprecated attribute intra-doc link not resolved in the right location on reexported item Fixes rust-lang#151028. Follow-up of rust-lang#150721. So when we resolve an intra-doc link, its current context (the module from which we resolve in short) is very important. However, when we use an intra-doc link in a `#[deprecated]` attribute on a reexported item, we were using the context of the reexported item and not of the `use` itself. Meaning that if you have an intra-doc link `std::mem::drop` on an item from another crate (let's say `core`), then the import will simply fail since there is no `std` dependency. Now comes the not so funny fix: at this point, we don't know anymore where the attribute came from (ie, from the reexport or from the reexported item) since we already merged the attribute at this point. The solution I found to go around this problem is to check if the item span contains the attribute, and if not, then we use the `inline_stmt_id` as context instead of the item's ID. I'm not super happy and I'm sure we'll find corner cases in the future (like with macros), however there are a few things that mitigate this fix: 1. The only way to generate an attribute with a macro with its item while having different spans is by using proc-macros. In that case, we can always default to the `inline_stmt_id` as context and be fine, but I guess we'll see when get there. 2. It only concerns reexports, so the area of the problem is quite restricted. Hopefully this explanation made sense. :) cc @folkertdev r? @lolbinarycat
…thar Preliminary match/capture test cleanup for PR 150681 Review for rust-lang#150681 requested that this cleanup gets extracted to a separate PR. r? @Zalathar
Reorganizing `tests/ui/issues` 5 tests [1/N] part of rust-lang#133895 r? Kivooeo
feat: Support references in reflection type info Tracking issue: rust-lang#146922 `#![feature(type_info)]` Based on rust-lang#151119 implementation for pointers for consistency r? oli-obk
|
Rollup of everything. @bors r+ rollup=never p=5 |
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: 1a9f1686b2 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 1a9f168 (parent) -> defdb83 (this PR) Test differencesShow 26 test diffsStage 1
Stage 2
Additionally, 2 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard defdb83d4bde9406ec4b37dd3dd572c1d70a14ca --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (defdb83): comparison URL. Overall result: ❌✅ regressions and improvements - BENCHMARK(S) FAILED@rustbot label: -perf-regression ❗ ❗ ❗ ❗ ❗
❗ ❗ ❗ ❗ ❗ cc @rust-lang/wg-compiler-performance Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 475.705s -> 475.301s (-0.08%) |
|
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (bb45796): comparison URL. Overall result: no relevant changes - BENCHMARK(S) FAILED❗ ❗ ❗ ❗ ❗
❗ ❗ ❗ ❗ ❗ Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. 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: missing data |
|
@Kobzol FYI, looks like this unrolled perf job was unable to find some artifacts: |
|
Yeah, it's still the same issue, the perf. run cannot be started until the unrolled CI finishes :( |
|
Really, something must have changed with the new runner arch. My, possibly faulty, recollection is this had never happened before. Can it be just about timing, CI getting slower, the perf runs dequeue faster, etc? |
|
Yeah it used to work with the old design. Before, the collector essentially entered an endless loop where it tried to download the artifacts, and would try it forever. So if CI succeeded, it would eventually work. Now, if we fail to download the artifacts, we report an error. Which is IMO sensible, but for this use-case annoying. I plan to fix it, but it will require non-trivial changes. |
Successful merges:
tests/ui/issues5 tests [1/N] #151221 (Reorganizingtests/ui/issues5 tests [1/N])r? @ghost
Create a similar rollup