https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.78.0 2024-03-14T19:00:19+00:00 2024-03-14T19:00:19+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-14T19:00:19+00:00 urn:sha1:54a5a49af0f836b9224e4750a2b577ed0ec2014a coverage: Initial support for branch coverage instrumentation (This is a review-ready version of the changes that were drafted in #118305.) This PR adds support for branch coverage instrumentation, gated behind the unstable flag value `-Zcoverage-options=branch`. (Coverage instrumentation must also be enabled with `-Cinstrument-coverage`.) During THIR-to-MIR lowering (MIR building), if branch coverage is enabled, we collect additional information about branch conditions and their corresponding then/else blocks. We inject special marker statements into those blocks, so that the `InstrumentCoverage` MIR pass can reliably identify them even after the initially-built MIR has been simplified and renumbered. The rest of the changes are mostly just plumbing needed to gather up the information that was collected during MIR building, and include it in the coverage metadata that we embed in the final binary. Note that `llvm-cov show` doesn't print branch coverage information in its source views by default; that needs to be explicitly enabled with `--show-branches=count` or similar. --- The current implementation doesn't have any support for instrumenting `if let` or let-chains. I think it's still useful without that, and adding it would be non-trivial, so I'm happy to leave that for future work. 2024-03-14T19:00:18+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-14T19:00:18+00:00 urn:sha1:722514f46626bbc1af8525f8f31c9a089f5b4f0f Copy byval argument to alloca if alignment is insufficient Fixes #122211 "Ignore whitespace" recommended. 2024-03-14T06:19:02+00:00 Zalathar Zalathar@users.noreply.github.com 2023-11-16T06:48:23+00:00 urn:sha1:31d0b5017857cef35031a7d4210bd045758dcae2 2024-03-13T09:43:35+00:00 Zalathar Zalathar@users.noreply.github.com 2024-02-08T01:39:15+00:00 urn:sha1:c921ab17134a7e526ec9df3942890f5b501addcb 2024-03-13T05:41:22+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-13T05:41:22+00:00 urn:sha1:8b9ef3b99627b8469e48dbb237e4a1d604985457 coverage: Remove or migrate all unstable values of `-Cinstrument-coverage` (This PR was substantially overhauled from its original version, which migrated all of the existing unstable values intact.) This PR takes the three nightly-only values that are currently accepted by `-Cinstrument-coverage`, completely removes two of them (`except-unused-functions` and `except-unused-generics`), and migrates the third (`branch`) over to a newly-introduced unstable flag `-Zcoverage-options`. I have a few motivations for wanting to do this: - It's unclear whether anyone actually uses the `except-unused-*` values, so this serves as an opportunity to either remove them, or prompt existing users to object to their removal. - After #117199, the stable values of `-Cinstrument-coverage` treat it as a boolean-valued flag, so having nightly-only extra values feels out-of-place. - Nightly-only values also require extra ad-hoc code to make sure they aren't accidentally exposed to stable users. - The new system allows multiple different settings to be toggled independently, which isn't possible in the current single-value system. - The new system makes it easier to introduce new behaviour behind an unstable toggle, and then gather nightly-user feedback before possibly making it the default behaviour for all users. - The new system also gives us a convenient place to put relatively-narrow options that won't ever be the default, but that nightly users might still want access to. - It's likely that we will eventually want to give stable users more fine-grained control over coverage instrumentation. The new flag serves as a prototype of what that stable UI might eventually look like. The `branch` option is a placeholder that currently does nothing. It will be used by #122322 to opt into branch coverage instrumentation. --- I see `-Zcoverage-options` as something that will exist more-or-less indefinitely, though individual sub-options might come and go as appropriate. I think there will always be some demand for nightly-only toggles, so I don't see `-Zcoverage-options` itself ever being stable, though we might eventually stabilize something similar to it. 2024-03-13T00:14:09+00:00 Zalathar Zalathar@users.noreply.github.com 2024-03-12T01:30:33+00:00 urn:sha1:1f544ce305bc207c9d0539938219caf01ea230c9 2024-03-13T00:03:50+00:00 bors bors@rust-lang.org 2024-03-13T00:03:50+00:00 urn:sha1:e61dcc7a0ac33ef054d76453307124233edcf545 Only generate a ptrtoint in AtomicPtr codegen when absolutely necessary This special case was added in this PR: https://github.com/rust-lang/rust/pull/77611 in response to this error message: ``` Intrinsic has incorrect argument type! void ({}*)* `@llvm.ppc.cfence.p0sl_s` in function rust_oom LLVM ERROR: Broken function found, compilation aborted! [RUSTC-TIMING] std test:false 20.161 error: could not compile `std` ``` But when I tried searching for more information about that intrinsic I found this: https://github.com/llvm/llvm-project/issues/55983 which is a report of someone hitting this same error and a fix was landed in LLVM, 2 years after the above Rust PR. 2024-03-12T10:29:15+00:00 bors bors@rust-lang.org 2024-03-12T10:29:15+00:00 urn:sha1:3b85d2c7fc6d1698e68b94f7bc1a5c9633f2554d Ensure nested allocations in statics neither get deduplicated nor duplicated This PR generates new `DefId`s for nested allocations in static items and feeds all the right queries to make the compiler believe these are regular `static` items. I chose this design, because all other designs are fragile and make the compiler horribly complex for such a niche use case. At present this wrecks incremental compilation performance *in case nested allocations exist* (because any query creating a `DefId` will be recomputed and never loaded from the cache). This will be resolved later in https://github.com/rust-lang/rust/pull/115613 . All other statics are unaffected by this change and will not have performance regressions (heh, famous last words) This PR contains various smaller refactorings that can be pulled out into separate PRs. It is best reviewed commit-by-commit. The last commit is where the actual magic happens. r? `@RalfJung` on the const interner and engine changes fixes https://github.com/rust-lang/rust/issues/79738 2024-03-12T08:51:20+00:00 Oli Scherer git-spam-no-reply9815368754983@oli-obk.de 2024-03-11T18:39:23+00:00 urn:sha1:e2773733f35f71dba92588d6b29e43d2cc035a34 2024-03-12T05:53:46+00:00 Oli Scherer git-spam-no-reply9815368754983@oli-obk.de 2024-02-26T18:03:06+00:00 urn:sha1:d3514a036dc65c1d31ee5b1b4bd58b9be1edf5af