https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2025-07-20T20:14:27+00:00 2025-07-20T20:14:27+00:00 Ralf Jung post@ralfj.de 2025-07-19T18:04:08+00:00 urn:sha1:3f9be406a6fd879a99a0eba33cc196fa2cb3957b 2025-07-19T08:29:13+00:00 Ralf Jung post@ralfj.de 2025-07-19T08:29:13+00:00 urn:sha1:7672e4ed85916d564d38dbd3a64803a45568504d 2025-07-18T17:14:47+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-18T17:14:47+00:00 urn:sha1:a59efc61f92e2ee047f72fde2494664e9a1793b8 Generalize `unsize` and `unsize_into` destinations Just something that I noticed during other work. We do this for most such functions, so let's do it here, too. r? ``@RalfJung`` 2025-07-18T17:14:43+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-18T17:14:43+00:00 urn:sha1:b3827e4f3728b77bd3e60587487ebfc3cc8d901b Show the offset, length and memory of uninit read errors r? ``@RalfJung`` I want to improve memory dumps in general. Not sure yet how to do so best within rust diagnostics, but in a perfect world I could generate a dummy in-memory file (that contains the rendered memory dump) that we then can then provide regular rustc `Span`s to. So we'd basically report normal diagnostics for them with squiggly lines and everything. 2025-07-18T13:09:34+00:00 Oli Scherer github333195615777966@oli-obk.de 2025-07-03T08:00:47+00:00 urn:sha1:c65d3ce365ecb6d6f36b413edb591d4746f52305 2025-07-18T02:27:51+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-18T02:27:51+00:00 urn:sha1:accf61dd42548bd5ec61d43f246b3eb499e980dd fix `-Zsanitizer=kcfi` on `#[naked]` functions fixes https://github.com/rust-lang/rust/issues/143266 With `-Zsanitizer=kcfi`, indirect calls happen via generated intermediate shim that forwards the call. The generated shim preserves the attributes of the original, including `#[unsafe(naked)]`. The shim is not a naked function though, and violates its invariants (like having a body that consists of a single `naked_asm!` call). My fix here is to match on the `InstanceKind`, and only use `codegen_naked_asm` when the instance is not a `ReifyShim`. That does beg the question whether there are other `InstanceKind`s that could come up. As far as I can tell the answer is no: calling via `dyn` seems to work find, and `#[track_caller]` is disallowed in combination with `#[naked]`. r? codegen ````@rustbot```` label +A-naked cc ````@maurer```` ````@rcvalle```` 2025-07-17T20:00:51+00:00 Oli Scherer github333195615777966@oli-obk.de 2025-06-18T12:51:47+00:00 urn:sha1:12eedafc38b1d3af02c9c15333d0ba2f1aee1253 2025-07-17T08:41:48+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-17T08:41:48+00:00 urn:sha1:e7efa044500a6f87d14e72342dba7751205c26f5 type_id_eq: check that the hash fully matches the type The previous logic wouldn't always detect when the hash mismatches the provenance. Fix that by adding a new helper, `read_type_id`, that reads a single type ID while fully checking it for validity and consistency. r? ``@oli-obk`` 2025-07-17T08:41:48+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-17T08:41:48+00:00 urn:sha1:4bf5787e2b952e8b432acc7b72d0f7e1838e8109 Make frame spans appear on a separate trace line This PR changes tracing_chrome's `tracing::Layer` so that if a span has the "tracing_separate_line" field as one of the span arguments, that span is put on a separate trace line. See https://github.com/rust-lang/miri/pull/4451 for an earlier attempt and for screenshots explaining better what I mean by "separate trace line". This PR also makes the "frame" span use this feature (so it appears on a separate trace line, see https://github.com/rust-lang/miri/pull/4451 for motivation), but passes `tracing::field::Empty` as the span parameter value so it is ignored by other tracing layers (e.g. the logger): ```rust info_span!("frame", tracing_separate_line = Empty, "{}", instance); ``` <details><summary>Also see the following discussion I had with ``@RalfJung</summary>`` > Is there no way to attach metadata we could use instead? [These](https://docs.rs/tracing-core/0.1.34/src/tracing_core/metadata.rs.html#57) are the **static** metadata items we can control about a span. We can't add more metadata outside of them. The most relevant are: - `name` (for the frame span it's currently "frame") - `target` which acts as the category (for the frame span it's currently "rustc_const_eval::interpret::stack" by default) - `fields` which contains a list of the *names* of each of the arguments passed to the `span!` macro (for the frame span it's currently ["message"], where "message" is the default identifier for data passed in the `format!` syntax) When the tracing code is called at runtime, the **dynamic** values of the arguments are collected into a [`ValueSet`](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#166). Each argument value stored there corresponds with one of the static names stored in `fields` (see above). --- We have already determined that filtering out spans by `name` is not a good idea, and I would say the same goes for `target`. Both the `name` and the `target` fields are printed to stderr when `MIRI_LOG=` is enabled, so changing them to contain an identifier (e.g. "frame:tracing_separate_root" instead of "frame" as the name) would uselessly clutter the text logs (unless we add one more filter [there](https://github.com/rust-lang/rust/blob/master/compiler/rustc_log/src/lib.rs#L137), but then it gets even more complicated). ```rust // examples of how the above (problematic) solutions would look like info_span!("frame:tracing_separate_root", "{}", instance); info_span!(target: "tracing_separate_root", "frame", "{}", instance); ``` --- So that leaves us with `fields` and their runtime values. Now, my initial thought (inspired by [this comment](https://github.com/rust-lang/miri/pull/4451#issuecomment-3068072303)) was to use a field with the static name "tracing_separate_root" and with a dynamic boolean value of "true". In `tracing_chrome.rs` we can easily check if this field is true and act accordingly. This would work but then again this field would also be picked up by the logger when `MIRI_LOG=` is enabled, and would uselessly clutter the text logs. ```rust // example of how the above (problematic) solution would look like info_span!("frame", tracing_separate_root = true, "{}", instance); ``` --- To avoid cluttering the text logs, we can instead set "tracing_separate_root" to the dynamic value of `tracing::field::Empty`. Citing from [here](https://docs.rs/tracing/0.1.41/tracing/field/struct.Empty.html), "when a field’s value is `Empty`, it will not be recorded". "not being recorded" means that the field and its value won't be printed to stderr text logs, nor will it be printed by any other tracing layers that might be attached in the future. In `tracing_chrome.rs` we would still be able to check if "tracing_separate_root" is in the list of static `fields`, and act accordingly. So I believe this solution would effectively allow us to attach metadata to a span in a way that does not clutter logs and still allows being read in `tracing_chrome.rs`. If we ever wanted to pass arbitrary metadata (i.e. not just a present/not present flag), it would be possible with a custom `Empty` that also holds data and implement `Value` without doing anything ([like `Empty` does](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#775)). ```rust // example of how the above solution would look like info_span!("frame", tracing_separate_root = tracing::field::Empty, "{}", instance); ``` </details> 2025-07-17T01:58:30+00:00 León Orell Valerian Liehr me@fmease.dev 2025-07-17T01:58:30+00:00 urn:sha1:83288db888606371dfac6491fc5720d31774aa8c add `const_make_global`; err for `const_allocate` ptrs if didn't call Implements as discussed on Zulip: [#t-compiler/const-eval > const heap](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const.20heap/with/527125421) r? ```@rust-lang/wg-const-eval``` Fixes https://github.com/rust-lang/rust/issues/129233