https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=stable 2025-05-06T10:42:25+00:00 2025-05-06T10:42:25+00:00 Zalathar Zalathar@users.noreply.github.com 2025-04-12T07:52:55+00:00 urn:sha1:4d5a1acebfe031ca2af75786295a2cd2a0633943 This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans. 2025-05-06T01:58:58+00:00 Zalathar Zalathar@users.noreply.github.com 2025-04-24T07:36:50+00:00 urn:sha1:c53a76743c01afa356ae5301bc1b35044354da7a 2025-02-13T02:45:53+00:00 Zalathar Zalathar@users.noreply.github.com 2025-02-11T03:09:11+00:00 urn:sha1:ab786d3b98d640b1208eff371c1184e3e8ce1d17 When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely. 2024-12-23T01:30:37+00:00 Zalathar Zalathar@users.noreply.github.com 2024-12-22T03:26:54+00:00 urn:sha1:87c2f9a5be900e835f3c41cec2886d54ec0ca012 This reverts commit 1d35638dc38dbfbf1cc2a9823135dfcf3c650169, reversing changes made to f23a80a4c2fbca593b64e70f5970368824b4c5e9. 2024-12-17T02:07:06+00:00 ltdk usr@ltdk.xyz 2024-09-23T23:40:22+00:00 urn:sha1:cb487cc2fa3c5ebfddd22d6721cf1669943c1774 2024-12-05T22:14:17+00:00 Eric Holk ericholk@microsoft.com 2024-11-16T01:42:09+00:00 urn:sha1:72ce1ab42f3be927f6f039a592222e054a0b0eaf Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com> 2024-11-08T09:43:08+00:00 Zalathar Zalathar@users.noreply.github.com 2024-11-05T10:59:10+00:00 urn:sha1:3c30fe3423b1e7d92584436493bd8fa6f17e13d0 2024-10-11T10:04:37+00:00 Zalathar Zalathar@users.noreply.github.com 2024-10-08T02:13:05+00:00 urn:sha1:599f95ecc26fb68cccbf79780dd1825a4cf73eb0 When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.) 2024-09-10T06:08:36+00:00 Zalathar Zalathar@users.noreply.github.com 2024-09-06T05:41:10+00:00 urn:sha1:e96b4e479a3835d43d3c0bfd1028b5ac9d99cfec By moving `block_on` to an auxiliary crate, we avoid having to keep a separate copy of it in every async test. (This also incorporates some small tweaks to the headers in `await_ready.rs`.) 2024-05-14T03:58:40+00:00 Zalathar Zalathar@users.noreply.github.com 2024-05-14T03:51:24+00:00 urn:sha1:d01df6f9aadf58a00357bd89b8fc25a44822ba77 Some of these cases currently don't occur in practice, but are included for completeness, and to avoid having to add them later as branch coverage and MC/DC coverage start building more complex expressions.