https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.77.2 2024-01-30T04:43:10+00:00 2024-01-30T04:43:10+00:00 yukang moorekang@gmail.com 2024-01-30T04:42:29+00:00 urn:sha1:ad526d831e295facc198610a27350076aa5aa438 2024-01-11T05:43:12+00:00 Zalathar Zalathar@users.noreply.github.com 2023-12-28T03:07:18+00:00 urn:sha1:124fff0777014323be34f0a990c78c5cfe9f40db 2024-01-02T11:57:04+00:00 Zalathar Zalathar@users.noreply.github.com 2024-01-02T11:57:04+00:00 urn:sha1:5e7c1b93ac7f5fb1bd5297980e8b6b3657a10c32 When #118865 started enforcing the `rustc::potential_query_instability` lint in `rustc_codegen_llvm`, it added an exemption for this site, arguing that the entries are only used to create a list of filenames that is later sorted. However, the list of entries also gets traversed when creating the function coverage records in LLVM IR, which may be sensitive to hash-based ordering. This patch therefore changes `function_coverage_map` to use `FxIndexMap`, which should avoid hash-based instability by iterating in insertion order. 2023-12-16T00:10:11+00:00 Zalathar Zalathar@users.noreply.github.com 2023-12-12T02:49:19+00:00 urn:sha1:c57f28bbf75572e10c6165c33a2aef922315fdb4 Coverage marker statements should have no effect on codegen, but in some cases they could have the side-effect of creating a `func_coverage` entry for their enclosing function. That can lead to an ICE for functions that don't actually have any coverage spans. 2023-12-12T12:16:14+00:00 Martin Nordholts martin.nordholts@codetale.se 2023-12-12T12:14:53+00:00 urn:sha1:f44ccbab2bbdc538b739d6a1f5f9fbdb8339f8f8 Stop allowing `rustc::potential_query_instability` on all of `rustc_codegen_llvm` and instead allow it on a case-by-case basis. In this case, both instances are safe to allow. 2023-12-08T11:40:49+00:00 Zalathar Zalathar@users.noreply.github.com 2023-11-23T00:50:39+00:00 urn:sha1:44b47aa976d6a6bdd7eb1f99a8ee5270afbe993e There are cases where coverage instrumentation wants to show a span for some syntax element, but there is no MIR node that naturally carries that span, so the instrumentor can't see it. MIR building can now use this new kind of coverage statement to deliberately include those spans in MIR, attached to a dummy statement that has no other effect. 2023-11-26T13:05:08+00:00 bohan bohan-zhang@foxmail.com 2023-11-26T13:05:08+00:00 urn:sha1:f23befe6c118573a2ca041bc89f959a8813b43a2 2023-11-22T07:37:14+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-11-21T05:35:26+00:00 urn:sha1:3ef9d4d0ed608b0493d66ffe8af2755529ce474c By default, `newtype_index!` types get a default `Encodable`/`Decodable` impl. You can opt out of this with `custom_encodable`. Opting out is the opposite to how Rust normally works with autogenerated (derived) impls. This commit inverts the behaviour, replacing `custom_encodable` with `encodable` which opts into the default `Encodable`/`Decodable` impl. Only 23 of the 59 `newtype_index!` occurrences need `encodable`. Even better, there were eight crates with a dependency on `rustc_serialize` just from unused default `Encodable`/`Decodable` impls. This commit removes that dependency from those eight crates. 2023-11-21T19:13:40+00:00 Nilstrieb 48135649+Nilstrieb@users.noreply.github.com 2023-11-21T19:07:32+00:00 urn:sha1:21a870515b18e5b2b90435d0f1a6d3089b5217ae `x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`. Then I had to remove a few unnecessary parens and muts that were exposed now. 2023-10-27T22:33:48+00:00 Zalathar Zalathar@users.noreply.github.com 2023-10-24T11:48:59+00:00 urn:sha1:230dd5b8c71c1d176a6705bb458a473411788f68