-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
Rollup of 3 pull requests #150334
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 3 pull requests #150334
Conversation
Unlike the other types covered by `PatConstKind::Other`, const-float patterns can also interact with range patterns.
stabilize `lazy_get` closes rust-lang#129333 FCP is finished in rust-lang#129333 (comment) ```@rustbot``` modify labels: +T-libs-api
Correct terminology in Clone I think the current wording around Clone here is confusing: - "Rust does not allow you to reimplement `Copy`" - reimplement isn't a piece of Rust terminology, but as written it sounds like you can't write `impl Copy for X`, which you can. - "you may reimplement `Clone`" - again reimplement isn't really a thing that you do to a trait, the distinction is between manually implementing and deriving. - "you can automatically make anything `Copy` be `Clone` as well" - you don't have a choice about it, so it doesn't really make sense to say you "can ... make" this happen.
mir_build: Classify `TestableCase::Constant` into multiple sub-kinds In match lowering, when choosing a test for a `TestableCase::Constant`, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test. Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering `thir::PatKind::Constant` to `TestableCase::Constant`, and then have the later steps simply match on an enum variant. There should be no change to the resulting built MIR. (I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)
|
@bors r+ rollup=never p=3 |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: efa32de15b 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 efa32de (parent) -> c4aa646 (this PR) Test differencesShow 79 test diffs79 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c4aa646f15e40bd3e64ddb5017b7b89b3646ac99 --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 (c4aa646): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 5.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -3.9%)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: 484.408s -> 483.398s (-0.21%) |
Successful merges:
lazy_get#150016 (stabilizelazy_get)TestableCase::Constantinto multiple sub-kinds #150238 (mir_build: ClassifyTestableCase::Constantinto multiple sub-kinds)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup