https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.90.0 2025-07-28T08:50:59+00:00 2025-07-28T08:50:59+00:00 bors bors@rust-lang.org 2025-07-28T08:50:59+00:00 urn:sha1:65b6cdb6a6d33987b9d642a4882283c71fbe3957 Rollup of 7 pull requests Successful merges: - rust-lang/rust#144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs) - rust-lang/rust#144151 (`tests/ui/issues/`: The Issues Strike Back [1/N]) - rust-lang/rust#144300 (Clippy fixes for miropt-test-tools) - rust-lang/rust#144399 (Add a ratchet for moving all standard library tests to separate packages) - rust-lang/rust#144472 (str: Mark unstable `round_char_boundary` feature functions as const) - rust-lang/rust#144503 (Various refactors to the codegen coordinator code (part 3)) - rust-lang/rust#144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`) r? `@ghost` `@rustbot` modify labels: rollup 2025-07-28T06:36:54+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-28T06:36:54+00:00 urn:sha1:ec86930c1d909b8114ce055c69746ca2c84b2ef4 Various refactors to the codegen coordinator code (part 3) Continuing from https://github.com/rust-lang/rust/pull/144062 this removes an option without any known users, uses the object crate in favor of LLVM for getting the LTO bitcode and improves the coordinator channel handling. 2025-07-28T05:25:23+00:00 bors bors@rust-lang.org 2025-07-28T05:25:23+00:00 urn:sha1:d242a8bd5a73f633ba1ec5aacf19acf35a3c747d Some `let chains` clean-up Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one r? compiler 2025-07-28T01:10:36+00:00 Kivooeo Kivooeo123@gmail.com 2025-07-26T01:22:20+00:00 urn:sha1:b8eb046e6ee3294969bf8faf31da226b0ea29d18 2025-07-26T13:52:24+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-07-06T18:03:07+00:00 urn:sha1:948f7798d70b6adb6a490b8867e155dadebd3f0e Nobody seems to actually use this, while still adding some extra complexity to the already rather complex codegen coordinator code. It is also not supported by any backend other than the LLVM backend. 2025-07-25T20:24:21+00:00 Jakub Beránek berykubik@gmail.com 2025-07-25T18:45:00+00:00 urn:sha1:4ef18ab06206f447d887824eeb47f70cddffc6cc 2025-07-24T13:08:22+00:00 León Orell Valerian Liehr me@fmease.dev 2025-07-24T13:08:22+00:00 urn:sha1:2a8bb6eda19478177336315eec2b1925b829ecb3 Use serde for target spec json deserialize The previous manual parsing of `serde_json::Value` was a lot of complicated code and extremely error-prone. It was full of janky behavior like sometimes ignoring type errors, sometimes erroring for type errors, sometimes warning for type errors, and sometimes just ICEing for type errors (the icing on the top). Additionally, many of the error messages about allowed values were out of date because they were in a completely different place than the FromStr impls. Overall, the system caused confusion for users. I also found the old deserialization code annoying to read. Whenever a `key!` invocation was found, one had to first look for the right macro arm, and no go to definition could help. This PR replaces all this manual parsing with a 2-step process involving serde. First, the string is parsed into a `TargetSpecJson` struct. This struct is a 1:1 representation of the spec JSON. It already parses all the enums and is very simple to read and write. Then, the fields from this struct are copied into the actual `Target`. The reason for this two-step process instead of just serializing into a `Target` is because of a few reasons 1. There are a few transformations performed between the two formats 2. The default logic is implemented this way. Otherwise all the default field values would have to be spelled out again, which is suboptimal. With this logic, they fall out naturally, because everything in the json struct is an `Option`. Overall, the mapping is pretty simple, with the vast majority of fields just doing a 1:1 mapping that is captured by two macros. I have deliberately avoided making the macros generic to keep them simple. All the `FromStr` impls now have the error message right inside them, which increases the chance of it being up to date. Some "`from_str`" impls were turned into proper `FromStr` impls to support this. The new code is much less involved, delegating all the JSON parsing logic to serde, without any manual type matching. This change introduces a few breaking changes for consumers. While it is possible to use this format on stable, it is very much subject to change, so breaking changes are expected. The hope is also that because of the way stricter behavior, breaking changes are easier to deal with, as they come with clearer error messages. 1. Invalid types now always error, everywhere. Previously, they would sometimes error, and sometimes just be ignored (which meant the users JSON was still broken, just silently!) 2. This now makes use of `deny_unknown_fields` instead of just warning on unused fields, which was done previously. Serde doesn't make it easy to get such warning behavior, which was the primary reason that this now changed. But I think error behavior is very reasonable too. If someone has random stale fields in their JSON, it is likely because these fields did something at some point but no longer do, and the user likely wants to be informed of this so they can figure out what to do. This is also relevant for the future. If we remove a field but someone has it set, it probably makes sense for them to take a look whether they need this and should look for alternatives, or whether they can just delete it. Overall, the JSON is made more explicit. This is the only expected breakage, but there could also be small breakage from small mistakes. All targets roundtrip though, so it can't be anything too major. fixes rust-lang/rust#144153 2025-07-21T17:32:44+00:00 Noratrieb 48135649+Noratrieb@users.noreply.github.com 2025-07-20T12:35:43+00:00 urn:sha1:dad96b107c0dd35ce2eecfaecc0e6af4988b3bb4 The previous manual parsing of `serde_json::Value` was a lot of complicated code and extremely error-prone. It was full of janky behavior like sometimes ignoring type errors, sometimes erroring for type errors, sometimes warning for type errors, and sometimes just ICEing for type errors (the icing on the top). Additionally, many of the error messages about allowed values were out of date because they were in a completely different place than the FromStr impls. Overall, the system caused confusion for users. I also found the old deserialization code annoying to read. Whenever a `key!` invocation was found, one had to first look for the right macro arm, and no go to definition could help. This PR replaces all this manual parsing with a 2-step process involving serde. First, the string is parsed into a `TargetSpecJson` struct. This struct is a 1:1 representation of the spec JSON. It already parses all the enums and is very simple to read and write. Then, the fields from this struct are copied into the actual `Target`. The reason for this two-step process instead of just serializing into a `Target` is because of a few reasons 1. There are a few transformations performed between the two formats 2. The default logic is implemented this way. Otherwise all the default field values would have to be spelled out again, which is suboptimal. With this logic, they fall out naturally, because everything in the json struct is an `Option`. Overall, the mapping is pretty simple, with the vast majority of fields just doing a 1:1 mapping that is captured by two macros. I have deliberately avoided making the macros generic to keep them simple. All the `FromStr` impls now have the error message right inside them, which increases the chance of it being up to date. Some "`from_str`" impls were turned into proper `FromStr` impls to support this. The new code is much less involved, delegating all the JSON parsing logic to serde, without any manual type matching. This change introduces a few breaking changes for consumers. While it is possible to use this format on stable, it is very much subject to change, so breaking changes are expected. The hope is also that because of the way stricter behavior, breaking changes are easier to deal with, as they come with clearer error messages. 1. Invalid types now always error, everywhere. Previously, they would sometimes error, and sometimes just be ignored (which meant the users JSON was still broken, just silently!) 2. This now makes use of `deny_unknown_fields` instead of just warning on unused fields, which was done previously. Serde doesn't make it easy to get such warning behavior, which was the primary reason that this now changed. But I think error behavior is very reasonable too. If someone has random stale fields in their JSON, it is likely because these fields did something at some point but no longer do, and the user likely wants to be informed of this so they can figure out what to do. This is also relevant for the future. If we remove a field but someone has it set, it probably makes sense for them to take a look whether they need this and should look for alternatives, or whether they can just delete it. Overall, the JSON is made more explicit. This is the only expected breakage, but there could also be small breakage from small mistakes. All targets roundtrip though, so it can't be anything too major. 2025-07-18T23:24:00+00:00 Manuel Drehwald git@manuel.drehwald.info 2025-06-18T22:29:43+00:00 urn:sha1:634016478ec95c6ff933d32789e663ace78e8f82 2025-07-18T05:43:22+00:00 bors bors@rust-lang.org 2025-07-18T05:43:22+00:00 urn:sha1:6c0a912e5a45904cf537f34876b16ae71d899f86 Rollup of 11 pull requests Successful merges: - rust-lang/rust#142300 (Disable `tests/run-make/mte-ffi` because no CI runners have MTE extensions enabled) - rust-lang/rust#143271 (Store the type of each GVN value) - rust-lang/rust#143293 (fix `-Zsanitizer=kcfi` on `#[naked]` functions) - rust-lang/rust#143719 (Emit warning when there is no space between `-o` and arg) - rust-lang/rust#143846 (pass --gc-sections if -Zexport-executable-symbols is enabled and improve tests) - rust-lang/rust#143891 (Port `#[coverage]` to the new attribute system) - rust-lang/rust#143967 (constify `Option` methods) - rust-lang/rust#144008 (Fix false positive double negations with macro invocation) - rust-lang/rust#144010 (Boostrap: add warning on `optimize = false`) - rust-lang/rust#144049 (rustc-dev-guide subtree update) - rust-lang/rust#144056 (Copy GCC sources into the build directory even outside CI) r? `@ghost` `@rustbot` modify labels: rollup