profile
viewpoint
Mark Rousskov Mark-Simulacrum Rust core and infra team member; Release team lead.

Mark-Simulacrum/bisect-rust 20

Bisects rust-lang/rust by pull request, downloading the built artifacts

Mark-Simulacrum/attractifier 3

Attractifier generates attractive JavaScript code from ugly JavaScript code.

Mark-Simulacrum/advent-of-code 1

Advent of Code solutions in Rust

Centril/crater-cat-errors 0

A quick hackily made program to aggregate all the errors in a crater run and which crates have them

Mark-Simulacrum/adjective-adjective-animal 0

Suitably random and reasonably unique human readable (and fairly adorable) ids, ala GiphyCat

Mark-Simulacrum/advent-of-code-2015 0

Each day of the 2015 Advent of Code. http://adventofcode.com/

Mark-Simulacrum/amd-bits 0

AMD loader built on top of bit-loader

Mark-Simulacrum/amd-resolver 0

Resolve AMD module names to File objects

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha ad354f4700cec6c66fdc0d2fb4cc24cb07894626

Drop script-servo-2 benchmark This benchmark takes 31% of our CI time, despite considerable time spent trying to optimize it. However, we have not found that it is particularly notable when compared to our other large crate benchmarks. script-servo has also historically shown some amount of non-determinism in the CGU partioning which also makes it an annoying benchmark. Most people profiling locally just disable it because of how long it takes.

view details

Mark Rousskov

commit sha b7fe2009bed8703962ae3ae7d069894e41d8d08c

Finish removal of script-servo by polishing CI

view details

Mark Rousskov

commit sha 2d31ccaa7b4e9affc63f2abaf07099e88ba333d8

Merge pull request #740 from Mark-Simulacrum/rm-script-servo Drop script-servo-2 benchmark

view details

push time in 8 hours

PR merged rust-lang/rustc-perf

Drop script-servo-2 benchmark

This benchmark takes 31% of our CI time, despite considerable time spent trying to optimize it. However, we have not found that it is particularly notable when compared to our other large crate benchmarks.

script-servo has also historically shown some amount of non-determinism in the CGU partioning which also makes it an annoying benchmark.

Most people profiling locally just disable it because of how long it takes.

r? @nnethercote

+3 -486498

1 comment

1895 changed files

Mark-Simulacrum

pr closed time in 8 hours

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 02d4a0e2be91bc0f327395184e2dc7f15a04e98a

Automatic stats update

view details

push time in 8 hours

PR opened rust-lang/rustc-perf

Drop script-servo-2 benchmark

This benchmark takes 31% of our CI time, despite considerable time spent trying to optimize it. However, we have not found that it is particularly notable when compared to our other large crate benchmarks.

script-servo has also historically shown some amount of non-determinism in the CGU partioning which also makes it an annoying benchmark.

Most people profiling locally just disable it because of how long it takes.

r? @nnethercote

+3 -486498

0 comment

1895 changed files

pr created time in 9 hours

create barnchMark-Simulacrum/rustc-perf

branch : rm-script-servo

created branch time in 9 hours

pull request commentrust-lang/rust

manually implement traits for Span

bors died so the build didn't get queued -- @lcnr, do you want to re-run try or we can invoke build on 9c509a323b82b57aae17bc2a2060471600a0307f?

lcnr

comment created time in 9 hours

pull request commentrust-lang/cargo

Fix close_output test.

From a "speed" perspective, do we have an idea of which is faster? I suspect the 1MB of output is faster personally, but maybe I'm wrong? We could also consider locking stdout in the loop instead of re-locking it on every iteration...

ehuss

comment created time in 10 hours

pull request commentrust-lang/rust

Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away

I don't think we can viably disable TCO. Plus, release + debuginfo is a common configuration, and we'd not want to hurt performance there.

I wouldn't mind a black_box where you suggest, but I suspect it won't help matters.

I'm fine with using bors to get the appropriate test outputs (we can just run it through as needed).

eggyal

comment created time in 10 hours

pull request commentrust-lang/rust

Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away

Let's add a new subdirectory and test files with // only-linux, // only-macos, // only-windows -- that way we can be sure this at least works on Tier 1 platforms. Ideally we'd have the same output across platforms but I'm not too worried if it's just the closure vanishing for whatever reason (which might even just be different unwinding implementation).

eggyal

comment created time in 10 hours

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 5dfa80236a98f4a0c44b638300a41e5e32780e30

Revert "Share target directories between benchmarks"

view details

Mark Rousskov

commit sha 12d89799daf792ff47f5266a22a8e55d3b5da3de

Merge pull request #739 from rust-lang/revert-738-share-build-cache Revert "Share target directories between benchmarks"

view details

push time in 10 hours

delete branch rust-lang/rustc-perf

delete branch : revert-738-share-build-cache

delete time in 10 hours

PR merged rust-lang/rustc-perf

Revert "Share target directories between benchmarks"

Reverts rust-lang/rustc-perf#738

It appears to be a performance regression (up 5 minutes on the collector).

+31 -66

2 comments

2 changed files

Mark-Simulacrum

pr closed time in 10 hours

pull request commentrust-lang/rustc-perf

Revert "Share target directories between benchmarks"

4014.562306732s w/o shared cache 4160.392478718s w/ shared cache

Reverting.

Mark-Simulacrum

comment created time in 10 hours

pull request commentrust-lang/rustc-perf

Revert "Share target directories between benchmarks"

I'm going to hold off on merging this until I finish a local collection with this on -- without, I see a full build taking 4014 seconds. If this is faster locally then I'll see if we can't reproduce that on the collector somehow before landing this.

Mark-Simulacrum

comment created time in 11 hours

PR opened rust-lang/rustc-perf

Revert "Share target directories between benchmarks"

Reverts rust-lang/rustc-perf#738

It appears to be a performance regression (up 5 minutes on the collector).

+31 -66

0 comment

2 changed files

pr created time in 11 hours

create barnchrust-lang/rustc-perf

branch : revert-738-share-build-cache

created branch time in 11 hours

pull request commentrust-lang/rust

Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away

@bors r+ rollup=iffy -- not sure if the added test will have the exact same output on other platforms

eggyal

comment created time in 11 hours

pull request commentrust-lang/rustc-perf

Share target directories between benchmarks

Okay this does indeed seem to be a regression:

  • 01:47:05 before this landed
  • 01:51:52 after this landed

Nothing obviously slower landed in rustc in that time either. I am unsure yet if there's some room for wins here or if we should just revert.

Mark-Simulacrum

comment created time in 11 hours

pull request commentrust-lang/rust

Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away

This looks great. Could you squash the commits into just the one to clean up git history a bit?

I suspect that this PR might cause problems if there's cases or platforms where our mini-functions get elided regardless of the black box, but we can iron out the kinks in nightly -- I don't think we'll find them by just looking in this PR, and it's small enough that I am comfortable just landing it.

r=me with commits squashed

eggyal

comment created time in 12 hours

pull request commentrust-lang/rust

New MIR optimization pass to reduce branches on match of tuples of enums

You likely need to edit the 32-bit tests (which are not run on 64-bit machines) -- I would personally just do so manually. I wish we had a better way to support developers in doing this.

simonvandel

comment created time in 12 hours

pull request commentrust-lang/rust

Add `#[cfg(panic = '...')]`

I personally suspect that no matter what we do, adding this basically stabilizes that there's only two panic strategies -- there is all but guaranteed to be downstream breakage in the wild no matter how we go about stabilizing.

This also increases the chances of crates saying "I only work with panic = abort" or so, whereas today the lack of this cfg means that it is pretty hard to make that call as a crate author (unless in some very specialized domain, where unwinding is never permitted, but those seem like major exceptions).

Looking at the use cases given so far (though I recall @joshtriplett mentioning others, maybe you can elaborate?):

https://github.com/rust-lang/rust/issues/74301 notes should_panic tests behaving poorly in -Cpanic=abort mode. This is "expected" -- and also seems solvable without this feature. The compiler can annotate such tests specially in -Cpanic=abort mode and libtest can use the already existing process-per-test mode for them. Perhaps there's room for a #[in_a_process] flag as well that users can opt-in to.

https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 discusses a limitation of our compiletest infrastructure, rather than a language limitation. It does seem true that some tests / programs require panic=abort to be sound (or panic=unwind to work), but this cfg seems like the wrong way to go about that. Like mentioned around the oneof RFC, maybe it merits a dedicated compile_error_if!(panic = abort, "....") but not general cfg support.

davidhewitt

comment created time in 12 hours

issue commentrust-lang/compiler-team-prioritization

Automate toolstate checks

I would not be opposed to automating this, but I personally think that it really does need a personal (human) touch with the current setup at least. Usually toolstate breakage is fixed out-of-tree -- sometimes spanning 4+ repositories -- and that progress is incredibly hard for a bot to find and track. While we could ask that folks update the main issue, ultimately, the assessment that needs to be made each time is:

  • Is this issue at risk of stagnating? (e.g., rustfmt devs are stuck on how to upgrade)
  • Are we close enough to a release (less than a week) that we should ping compiler team to coordinate fixing, bypassing tool devs?

I don't think automation can make either call today.

spastorino

comment created time in 12 hours

delete branch Mark-Simulacrum/rustc-perf

delete branch : share-build-cache

delete time in 14 hours

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha ae5fae1abbcdaea063563bb341f6495be90494fc

Share initial build cache across all benchmarks Previously, each benchmark would rebuild dependencies from scratch, which was somewhat inefficient: many dependencies in Rust are shared amongst crates (e.g., syn, serde). This shares them across all benchmarks. The next step would be to go further, and share between build kinds (e.g., build scripts only need to be built once). But we don't actually have a good way of doing so, so that's left out of scope for now.

view details

Mark Rousskov

commit sha f24e8318a285e6b128e7a12867d4cf1ee6fccc67

Share target directories between benchmarks

view details

Mark Rousskov

commit sha e38d3056f82158b4d6ac7d8744ac357d75ed77e8

Profilers write to cwd, not target directory

view details

Mark Rousskov

commit sha 2781848d04d7bbb281ffffa811a982060e495290

cargo llvm-lines doesn't support --target-dir

view details

Mark Rousskov

commit sha fe431ec1d7b385adf2e6c08fab4c9cb03f2c997b

Merge pull request #738 from Mark-Simulacrum/share-build-cache Share target directories between benchmarks

view details

push time in 14 hours

PR merged rust-lang/rustc-perf

Share target directories between benchmarks

Previously, each benchmark would rebuild dependencies from scratch, which was somewhat inefficient: many dependencies in Rust are shared amongst crates (e.g., syn, serde). This shares them across all benchmarks.

The next step would be to go further, and share between build kinds (e.g., build scripts only need to be built once). But we don't actually have a good way of just building build scripts, so that's left out of scope for now. It is also unclear how big a win this would be.

+66 -31

2 comments

2 changed files

Mark-Simulacrum

pr closed time in 14 hours

pull request commentrust-lang/rustc-perf

Share target directories between benchmarks

I am struggling to gather local numbers (still getting environment setup on a new computer), but I suspect that regardless the discrepancy in available parallelism and such may mean that I wouldn't really reflect what happens in prod anyway. I'm going to merge this. It is passing CI, and it should not affect the final crate's builds. In the worst case we can revert and delete generated artifacts if something does go wrong unexpectedly.

Mark-Simulacrum

comment created time in 14 hours

pull request commentrust-lang/rust

Use `tracing` spans to trace the entire MIR interp stack

rustc always uses threads for LLVM, at least, so it probably makes sense to just always include a thread ID.

oli-obk

comment created time in 16 hours

pull request commentrust-lang/rust

Use `tracing` spans to trace the entire MIR interp stack

I think I would personally prefer that we not try to introduce locks or anything into rustc itself but rather have a separate tool that parses and re-shuffles logger output -- is that feasible? Too hard?

oli-obk

comment created time in 17 hours

pull request commentrust-lang/rust

Disable polymorphisation

Thanks! Is that something we could plausibly "fix", or does that seem too hard? I guess we're already encoding them as bitsets. Maybe we can skip recording all-zero bitsets and decode them appropriately as well? It may also be worth switching to a lower minimum bound -- u64 implies 64 generics which I expect is way above the normal amount for most functions?

davidtwco

comment created time in 17 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

I prefer to provide them on-demand as the exact setup can change over time, but just give me a ping whenever you need it!

richkadel

comment created time in 17 hours

issue openedrust-lang/lang-team

Require ABI for extern in 2021

Proposal

Summary and problem statement

We do not currently require users to specify which ABI an extern corresponds to, in any context. This can be confusing (e.g., see https://github.com/rust-lang/rust/pull/75030), and seems like an obvious case to fix. Requiring users to specify the ABI forces them to think through which ABI they want.

Motivation, use-cases, and solution sketches

The primary motivation is to ease reading code. Particularly with the introduction of "C-unwind" ABI, it seems increasingly true that knowing up front which ABI is associated with function pointers and function declarations is useful.

Prioritization

I think this best fits the targeted ergonomic wins -- similar to dyn, at least for me, seeing extern "C" is much clearer than just a bare extern. Though related to C Parity / embedded, it does not enable any new behavior that was absent previously.

Links and related work

C++ mandates only C and C++ ABIs, and requires an ABI to be specified on extern blocks, but not extern functions.

Initial people involved

No one beyond myself, at this point.

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

created time in 17 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

Hm, no, that change just disabled the Azure try builder (we're on GHA now), but both ran the same docker container.

Maybe you're confusing the try builds for x86_64-gnu-llvm-8 which runs in PR CI? That does run tests.

Regardless, we can run tests in try or so if needed, happy to provide instructions on how to enable that today.

richkadel

comment created time in 17 hours

pull request commentrust-lang/rustc-perf

Share target directories between benchmarks

I am working on gathering local numbers for how much of a win this is -- it seems like it might actually be a loss (perhaps from increased copying) on CI...

Mark-Simulacrum

comment created time in 17 hours

pull request commentrust-lang/rust

mv std libs to library/

That looks reasonable. I think the md5 hashing is presumably from encoding md5 hashes into debuginfo. Maybe we can consider some sort of partial hashing scheme -- many files are going to all be at some prefix, and we can pre-hash that prefix I guess?

Not sure how feasible such a cache would be though.

mark-i-m

comment created time in 18 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

bors try has not run tests on linux (or any platform) by default for at least the last few months, and I think roughly a year or so now (maybe more). It only does a dist build. https://github.com/rust-lang-ci/rust/actions is your best bet for finding logs if they're not cross-linked from the PR the try build was invoked on for whatever reason.

richkadel

comment created time in 18 hours

push eventMark-Simulacrum/rustc-perf

Mark Rousskov

commit sha 2781848d04d7bbb281ffffa811a982060e495290

cargo llvm-lines doesn't support --target-dir

view details

push time in 18 hours

push eventMark-Simulacrum/rustc-perf

Mark Rousskov

commit sha e38d3056f82158b4d6ac7d8744ac357d75ed77e8

Profilers write to cwd, not target directory

view details

push time in 18 hours

pull request commentrust-lang/rust

Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away

I think we should try to add a UI test for this. My guess is we can do that with a run-fail test, like this one https://github.com/rust-lang/rust/blob/master/src/test/ui/test-panic-abort.rs

eggyal

comment created time in 18 hours

push eventMark-Simulacrum/rustc-perf

Mark Rousskov

commit sha ae5fae1abbcdaea063563bb341f6495be90494fc

Share initial build cache across all benchmarks Previously, each benchmark would rebuild dependencies from scratch, which was somewhat inefficient: many dependencies in Rust are shared amongst crates (e.g., syn, serde). This shares them across all benchmarks. The next step would be to go further, and share between build kinds (e.g., build scripts only need to be built once). But we don't actually have a good way of doing so, so that's left out of scope for now.

view details

Mark Rousskov

commit sha f24e8318a285e6b128e7a12867d4cf1ee6fccc67

Share target directories between benchmarks

view details

push time in 19 hours

PR opened rust-lang/rustc-perf

Share target directories between benchmarks

Previously, each benchmark would rebuild dependencies from scratch, which was somewhat inefficient: many dependencies in Rust are shared amongst crates (e.g., syn, serde). This shares them across all benchmarks.

The next step would be to go further, and share between build kinds (e.g., build scripts only need to be built once). But we don't actually have a good way of just building build scripts, so that's left out of scope for now. It is also unclear how big a win this would be.

+66 -31

0 comment

2 changed files

pr created time in 19 hours

create barnchMark-Simulacrum/rustc-perf

branch : share-build-cache

created branch time in 19 hours

issue commentrust-lang/rust

Crater runs for 1.46

@craterbot run name=beta-1.46-rustdoc-1 start=1.45.2 end=beta-2020-07-24 mode=rustdoc cap-lints=warn p=5

Mark-Simulacrum

comment created time in 19 hours

issue commentrust-lang/rust

Crater runs for 1.46

@craterbot run name=beta-1.46-1 start=1.45.2 end=beta-2020-07-24 mode=build-and-test cap-lints=warn p=10

Mark-Simulacrum

comment created time in 19 hours

issue openedrust-lang/rust

Crater runs for 1.46

Note: Please do not conduct triage on these runs with syncing with a release team member first. Thanks!

created time in 19 hours

pull request commentrust-lang/rust

[CRATER] make `ConstEvaluatable` more strict

@craterbot retry

lcnr

comment created time in 19 hours

pull request commentrust-lang/rust

Update cargo

I don't think I've ever had a Rust project that was more than a week long and didn't always need release mode, but I agree that it probably varies quite a bit.

I think that this is probably still the right call, though.

One thing we could try is splitting the build dependencies of proc macros and build scripts apart - the latter matter much less, and always run once. But proc macros used for in-workspace crates are essentially guaranteed to be run hundreds of times, so optimizing them to shave of a few milliseconds can be helpful.

I think from scratch builds will indeed always be faster for this, but we also don't have a great handle on whether that matters today (i.e., if you're on CI you probably only care about them, but locally you usually care about tiny incremental rebuilds).

ehuss

comment created time in 21 hours

pull request commentrust-lang/rust

Avoid `unwrap_or_else` in str indexing

@bors r+

tmiasko

comment created time in 21 hours

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 8ad66103800d68c20b3f7d50c8aaeba01e31d6d1

Automatic stats update

view details

push time in a day

issue commentrust-lang/rust

Program crashes with #[track_caller] applied to main()

Cc @anp

We probably just want to ban track caller on main (and maybe any lang item function?)

flowbish

comment created time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha a22b1b2f947761f63bcd5b3c337f40a5d6567010

Add max-rss for gimli

view details

push time in a day

pull request commentrust-lang/rust

Avoid `unwrap_or_else` in str indexing

@bors try @rust-timer queue

This does indeed look better - I guess LLVM is probably probably propagates the cold attribute on the panicking and decides not to inline, though in this case that's not a good idea.

tmiasko

comment created time in a day

pull request commentrust-lang/rust

mv std libs to library/

cachegrind diffs are usually noiseless for me, or nearly so.

mark-i-m

comment created time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 37fa837bc64e57bc0a2f3b02424b4efdc71b0b9f

Update the revisions for this performance report. The starting revision is the *parent* of the first revision we actually check performance for this week; its performance was checked by last week's triage.

view details

push time in a day

pull request commentrust-lang/rust

mv std libs to library/

My guess is that someone with pretty decent hardware, just to avoid it being really painful, would need to build rustc before/after this PR, i.e., on 9be8ffcb0206fc1558069a7b4766090df7877659 and ac48e62db85e6db4bbe026490381ab205f4a614d and run cachegrind on a rustc compilation of helloworld. The diff between those should give us a start of an idea for how to fix this.

I've added this to my todo list.

mark-i-m

comment created time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 9759a23eeec79926358bfafc2143fbd05bb16250

Add links

view details

push time in a day

push eventMark-Simulacrum/this-week-in-rust

Mark Rousskov

commit sha 505bce399bce4b1be946d116f7f2b90eb1f05485

Add perf triage for this week.

view details

push time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha c32540e6c2df5383ba879f4977e42bbc3cca6bbd

Add counters

view details

push time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 42bca09a4f3ef889284045020882612eaf0d4f45

Add initial triage report for 2020-08-03

view details

push time in a day

pull request commentrust-lang/rust

Rollup of 10 pull requests

This was a slight performance regression, of up to 1%. Perhaps one of the BTree PRs are at fault? I recall there being some known regressions there.

JohnTitor

comment created time in a day

pull request commentrust-lang/rust

Move 'probably equal' methods to librustc_parse

This was a 1.1% regression for rustdoc on small crates. Probably different inlining decisions made by LLVM, or so? Does not affect rustc.

Aaron1011

comment created time in a day

pull request commentrust-lang/rust

Avoid `unwrap_or_else` in str indexing

This really leads to simpler assembly with optimizations? That seems pretty unfortunate, given that this is essentially equivalent. Do you have diffs of before/after assembly?

tmiasko

comment created time in a day

pull request commentrust-lang/rust

Move from `log` to `tracing`

This was a slight performance win, as expected. Huge thanks to @oli-obk and @hawkw for all the work put in here to get us an even faster logging framework. :tada:

oli-obk

comment created time in a day

pull request commentrust-lang/rust

Normalize all opaque types when converting ParamEnv to Reveal::All

This was a slight performance regression, as expected.

Aaron1011

comment created time in a day

issue commentrust-lang/rustc-perf

Track cache misses from perf counters.

https://gist.github.com/Mark-Simulacrum/151b4948d6bd1ab86b5c1d9b36ba64de is the current output of perf list on the collector.

eddyb

comment created time in a day

pull request commentrust-lang/rust

std: Switch from libbacktrace to gimli (take 2)

As expected, this was a performance regression of up to 20% on smaller crates, essentially entirely due to increased amount of metadata decoding. https://github.com/rust-lang/rust/pull/75008 may be the first step in eliminating these losses.

alexcrichton

comment created time in a day

pull request commentrust-lang/rust

Replace all uses of `log::log_enabled` with `Debug` printers

This was a slight performance regression on the ctfe stress test.

I suspect we're optimizing more poorly or something like that?

oli-obk

comment created time in a day

pull request commentrust-lang/rust

Update cargo

This was a performance regression, likely due to https://github.com/rust-lang/cargo/pull/8560.

Looking at the results, it seems the two crates affected, cargo and script-servo, had a roughly 0.5s and 0.8s bump in macro expansion.

This is presumably an expected (if somewhat unfortunate) consequence of the above PR -- it was all but guaranteed to be a regression on perf.rust-lang.org, as we only benchmark "final binary/library" compilation rather than the whole build. https://github.com/rust-lang/cargo/pull/8560 can only help full, post-cargo clean, builds.

ehuss

comment created time in a day

pull request commentrust-lang/rust

Cache non-exhaustive separately from attributes

This was a small perf improvement, as expected.

Mark-Simulacrum

comment created time in a day

delete branch Mark-Simulacrum/rust

delete branch : cache-non-exhaustive

delete time in a day

pull request commentrust-lang/rust

ci: disable fast-fail on auto-fallible

@bors r-

This seems to be a syntax errror (note - even PR CI didn't run).

The workflow is not valid. .github/workflows/ci.yml (Line: 578, Col: 7): Unexpected value 'fast-fail'

pietroalbini

comment created time in a day

PR closed rust-lang/rust

Rollup of 7 pull requests S-waiting-on-bors rollup

Successful merges:

  • #74759 (add unsigned_abs to signed integers)
  • #75056 (Lint path statements to suggest using drop when the type needs drop)
  • #75058 (Clarify reuse of a BTreeMap insert support function and treats split support likewise)
  • #75081 (Fix logging for rustdoc)
  • #75083 (Do not trigger unused_braces for while let)
  • #75095 (ci: disable fast-fail on auto-fallible)
  • #75103 (Disable building rust-analyzer on riscv64)

Failed merges:

r? @ghost

+180 -102

8 comments

12 changed files

Manishearth

pr closed time in a day

pull request commentrust-lang/rust

Rollup of 7 pull requests

@bors r-

The workflow is not valid. .github/workflows/ci.yml (Line: 578, Col: 7): Unexpected value 'fast-fail'

From https://github.com/rust-lang-ci/rust/actions/runs/193864895

Closing.

Manishearth

comment created time in a day

Pull request review commentrust-lang/rust

Stabilize deque_make_contiguous

 const MAXIMUM_ZST_CAPACITY: usize = 1 << (64 - 1); // Largest possible power of /// push onto the back in this manner, and iterating over `VecDeque` goes front /// to back. ///+/// Since `VecDeque` is a ring buffer, its elements are not necessarily contiguous+/// in memory. If you want to access the elements as a single slice, such as for+/// efficient sorting, you can use [`make_contiguous`]. It rotates the `VecDeque`

:+1: seems reasonable.

jonhoo

comment created time in a day

pull request commentrust-lang/rust

mv std libs to library/

Perf triage:

This was a slight regression. This seems unexpected. Perhaps metadata sizes increased so we're reading more from disk? It would be good to investigate this further.

mark-i-m

comment created time in a day

pull request commentrust-lang/rust

convert higher ranked `Predicate`s to `PredicateKind::ForAll`

Perf triage:

This was a 2.5% regression on stress tests and a 1-2% loss on serde and futures (real world tests). This was expected.

lcnr

comment created time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 8208ee63ff900a6645dc3da900cad09df8eacbe3

Display PR numbers (when available) in comparison UI

view details

push time in a day

push eventrust-lang/lang-team

Deploy from CI

commit sha a257ba4c8859f6c14c2856b8fb9ae687352fc0f3

Deploy 7003c03c1406ba3bbb28d265ec61b7c7591ceea6 to gh-pages

view details

push time in a day

pull request commentrust-lang/rust

Disable polymorphisation

@davidtwco, @wesleywiser -- could someone follow up on this being a performance-neutral PR? Thanks!

davidtwco

comment created time in a day

Pull request review commentrust-lang/rust

Stabilize deque_make_contiguous

 const MAXIMUM_ZST_CAPACITY: usize = 1 << (64 - 1); // Largest possible power of /// push onto the back in this manner, and iterating over `VecDeque` goes front /// to back. ///+/// Since `VecDeque` is a ring buffer, its elements are not necessarily contiguous+/// in memory. If you want to access the elements as a single slice, such as for+/// efficient sorting, you can use [`make_contiguous`]. It rotates the `VecDeque`

Hm -- I would expect that we could implement sorting almost as efficiently on two slices as one? We still have Index/IndexMut impls, so anything a sort would need to do seems like it should be essentially just as fast.

jonhoo

comment created time in a day

push eventrust-lang/lang-team

Deploy from CI

commit sha 0bf7bc821a7ae3c5790b6218fc27e0711db7edfb

Deploy bdd52b75257f3bad06cced7f0db08338869c856c to gh-pages

view details

push time in a day

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 0faec694d563ea30022f4e965a5e3e390f3275b0

Add next/previous buttons to compare page These enable easier navigation when conducting triage or otherwise checking results across some commit range. We also now warn if the current query is not viewing two adjacent commits, as that's usually a bad idea.

view details

push time in a day

Pull request review commentrust-lang/rust

BTreeMap: respect the panic rule imposed by `replace`

 use core::ptr;  use super::node::{marker, ForceResult::*, Handle, NodeRef};-use super::unwrap_unchecked;++/// `Option::unwrap` without the promise to panic if the option contains no value.+/// SAFETY: the caller must ensure that the option contains a value.+/// Cannot panic if the caller respects safety preconditions.+#[inline]+unsafe fn panicless_unwrap_unchecked<T>(val: Option<T>) -> T {+    val.unwrap_or_else(|| unsafe { core::hint::unreachable_unchecked() })+}  impl<BorrowType, K, V> Handle<NodeRef<BorrowType, K, V, marker::Leaf>, marker::Edge> {     /// Given a leaf edge handle, returns [`Result::Ok`] with a handle to the neighboring KV     /// on the right side, which is either in the same leaf node or in an ancestor node.     /// If the leaf edge is the last one in the tree, returns [`Result::Err`] with the root node.+    /// Cannot panic.

I don't think that's necessary. We do have #[unwind(aborts)] but using it throughout here is probably a bad idea - maybe not, not sure.

ssomers

comment created time in 2 days

pull request commentrust-lang/rust

Add `#[cfg(panic = '...')]`

One question I have -- should we be documenting this as an extensible set, i.e., panic = "somethingelse" would perhaps eventually be added? I note that the tests here, for example, explicitly use not(panic = "abort") in a few places.

I can't think of other panic implementation strategies that would be reasonable for code to gate on, but I'm not very familiar with the possibilities here.

One option, if we're concerned about this, is to designate aborting as "special" (since it is the immediate termination option) and only add that (or just leave unwind unstable indefinitely).

davidhewitt

comment created time in 2 days

push eventMark-Simulacrum/rustc-artifacts

Mark Rousskov

commit sha 351c152bca4e30a37e77e26bcd7758d3a9c8feee

Include parent_sha in output

view details

push time in 2 days

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha ad2948ca1d205bb8fc64ea30a24b66708ed2e58a

Fix table being altered

view details

push time in 2 days

delete branch Mark-Simulacrum/rustc-perf

delete branch : rustc-perf-commit

delete time in 2 days

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha b7739d6f528c6106d62bf71614ca14e6e1c7994e

Save git commit when collecting

view details

Mark Rousskov

commit sha c92a182abe9cfb7c6f4edf7eda8f9a7834784a41

Merge pull request #737 from Mark-Simulacrum/rustc-perf-commit Save git commit when collecting

view details

push time in 2 days

push eventMark-Simulacrum/rustc-perf

Mark Rousskov

commit sha b7739d6f528c6106d62bf71614ca14e6e1c7994e

Save git commit when collecting

view details

push time in 2 days

pull request commentrust-lang/rust

Add track_caller to RefCell::{borrow, borrow_mut}

Seems like a clear win. I don't think this is observable beyond the panic message being (much) better.

@bors r+

erikdesjardins

comment created time in 2 days

Pull request review commentrust-lang/rust

BTreeMap: respect the panic rule imposed by `replace`

 use core::ptr;  use super::node::{marker, ForceResult::*, Handle, NodeRef};-use super::unwrap_unchecked;++/// `Option::unwrap` without the promise to panic if the option contains no value.+/// SAFETY: the caller must ensure that the option contains a value.+/// Cannot panic if the caller respects safety preconditions.+#[inline]+unsafe fn panicless_unwrap_unchecked<T>(val: Option<T>) -> T {+    val.unwrap_or_else(|| unsafe { core::hint::unreachable_unchecked() })+}  impl<BorrowType, K, V> Handle<NodeRef<BorrowType, K, V, marker::Leaf>, marker::Edge> {     /// Given a leaf edge handle, returns [`Result::Ok`] with a handle to the neighboring KV     /// on the right side, which is either in the same leaf node or in an ancestor node.     /// If the leaf edge is the last one in the tree, returns [`Result::Err`] with the root node.+    /// Cannot panic.

This shouldn't be made into a safety section (that only makes sense for unsafe functions). However, adding a bit of text saying something like "panicking here leads to UB (or aborts) elsewhere in this module" would be fine.

ssomers

comment created time in 2 days

pull request commentrust-lang/rust

Make rust.use-lld config option work with non MSVC targets

@bors r+

mati865

comment created time in 2 days

push eventrust-lang/rustc-perf

Mark Rousskov

commit sha 8bf054b938f2aa7dfe78c09993481bbd7a82437e

Display PR number for master commits on status page This is not yet shown for all PRs as triagebot doesn't report it for all master commits (we only recently started collecting the data).

view details

push time in 2 days

push eventMark-Simulacrum/rustc-artifacts

Mark Rousskov

commit sha e03dc2a4de06ec9146c56bdce10d27777eda2e67

Bump to 0.2.1

view details

push time in 2 days

Pull request review commentrust-lang/rust

Make rust.use-lld config option work with non MSVC targets

 # Linker to be used to link Rust code. Note that the # default value is platform specific, and if not specified it may also depend on # what platform is crossing to what platform.-# Setting this will override the `use-lld` option for Rust code.+# Setting this will override the `use-lld` option for Rust code when targetting MSVC.
# Setting this will override the `use-lld` option for Rust code when targeting MSVC.
mati865

comment created time in 2 days

push eventMark-Simulacrum/rustc-artifacts

Mark Rousskov

commit sha 03fb4bf890eabd434350a8906c8360ae80e4c7f3

Add pull request information

view details

push time in 2 days

create barnchMark-Simulacrum/rustc-perf

branch : rustc-perf-commit

created branch time in 2 days

more