https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.89.0 2025-06-19T18:05:01+00:00 2025-06-19T18:05:01+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-06-19T18:05:01+00:00 urn:sha1:3388d837850eebca505350bc25f017276551a955 2025-06-19T18:03:17+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-06-17T21:59:57+00:00 urn:sha1:316f63bc48a9bfe26b2a8fc06e7eeef45ac2b7aa 2025-06-19T18:02:04+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-06-19T18:02:04+00:00 urn:sha1:07b9bb1855596ac84a80d898b40c4b403f1dcc3f 2025-06-18T17:40:32+00:00 Urgau 3616612+Urgau@users.noreply.github.com 2025-06-18T17:40:32+00:00 urn:sha1:2011ab51528ba9469ba313ff3c269b465d042f1d Implement initial support for timing sections (`--json=timings`) This PR implements initial support for emitting high-level compilation section timings. The idea is to provide a very lightweight way of emitting durations of various compilation sections (frontend, backend, linker, or on a more granular level macro expansion, typeck, borrowck, etc.). The ultimate goal is to stabilize this output (in some form), make Cargo pass `--json=timings` and then display this information in the HTML output of `cargo build --timings`, to make it easier to quickly profile "what takes so long" during the compilation of a Cargo project. I would personally also like if Cargo printed some of this information in the interactive `cargo build` output, but the `build --timings` use-case is the main one. Now, this information is already available with several other sources, but I don't think that we can just use them as they are, which is why I proposed a new way of outputting this data (`--json=timings`): - This data is available under `-Zself-profile`, but that is very expensive and forever unstable. It's just a too big of a hammer to tell us the duration it took to run the linker. - It could also be extracted with `-Ztime-passes`. That is pretty much "for free" in terms of performance, and it can be emitted in a structured form to JSON via `-Ztime-passes-format=json`. I guess that one alternative might be to stabilize this flag in some form, but that form might just be `--json=timings`? I guess what we could do in theory is take the already emitted time passes and reuse them for `--json=timings`. Happy to hear suggestions! I'm sending this PR mostly for a vibeck, to see if the way I implemented it is passable. There are some things to figure out: - How do we represent the sections? Originally I wanted to output `{ section, duration }`, but then I realized that it might be more useful to actually emit `start` and `end` events. Both because it enables to see the output incrementally (in case compilation takes a long time and you read the outputs directly, or Cargo decides to show this data in `cargo build` some day in the future), and because it makes it simpler to represent hierarchy (see below). The timestamps currently emit microseconds elapsed from a predetermined point in time (~start of rustc), but otherwise they are fully opaque, and should be only ever used to calculate the duration using `end - start`. We could also precompute the duration for the user in the `end` event, but that would require doing more work in rustc, which I would ideally like to avoid :P - Do we want to have some form of hierarchy? I think that it would be nice to show some more granular sections rather than just frontend/backend/linker (e.g. macro expansion, typeck and borrowck as a part of the frontend). But for that we would need some way of representing hierarchy. A simple way would be something like `{ parent: "frontend" }`, but I realized that with start/end timestamps we get the hierarchy "for free", only the client will need to reconstruct it from the order of start/end events (e.g. `start A`, `start B` means that `B` is a child of `A`). - What exactly do we want to stabilize? This is probably a question for later. I think that we should definitely stabilize the format of the emitted JSON objects, and *maybe* some specific section names (but we should also make it clear that they can be missing, e.g. you don't link everytime you invoke `rustc`). The PR be tested e.g. with `rustc +stage1 src/main.rs --json=timings --error-format=json -Zunstable-options` on a crate without dependencies (it is not easy to use `--json` with stock Cargo, because it also passes this flag to `rustc`, so this will later need Cargo integration to be usable with it). Zulip discussions: [#t-compiler > Outputting time spent in various compiler sections](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Outputting.20time.20spent.20in.20various.20compiler.20sections/with/518850162) MCP: https://github.com/rust-lang/compiler-team/issues/873 r? ``@nnethercote`` 2025-06-18T14:01:41+00:00 Romain Perier romain.perier@gmail.com 2025-05-25T13:15:49+00:00 urn:sha1:a1a3bef6f0d5f5f45f0296133d7af745dc89d7bb This commit adds a lint to prevent the use of rustc_type_ir in random compiler crates, except for type system internals traits, which are explicitly allowed. Moreover, this fixes diagnostic_items() to include the CRATE_OWNER_ID, otherwise rustc_diagnostic_item attribute is ignored on the crate root. 2025-06-16T09:51:17+00:00 Jakub Beránek berykubik@gmail.com 2025-06-06T15:12:55+00:00 urn:sha1:c9d305952e0a74a5d0428fed79b62487aefa41e4 2025-06-12T07:56:47+00:00 Jana Dönszelmann jana@donsz.nl 2025-02-12T12:59:08+00:00 urn:sha1:6072207a1151f212163e3c19d92ff4ea22f291b2 lint on duplicates during attribute parsing To do this we stuff them in the diagnostic context to be emitted after hir is constructed 2025-06-08T14:50:42+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-06-08T14:47:28+00:00 urn:sha1:9223704f4b92ded13090659f60afb98e52eabf1b 2025-06-07T07:49:29+00:00 Jubilee Young workingjubilee@gmail.com 2025-06-07T07:44:08+00:00 urn:sha1:5bab0d2e66f77e34865026856dcd5ae21f0b2d2f This silences an ICE. 2025-05-26T16:06:40+00:00 Nicholas Nethercote n.nethercote@gmail.com 2025-05-26T16:06:40+00:00 urn:sha1:19802e8e9cf2732768c89dcfe1c5fa0eb88cd558