https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.84.0 2024-11-03T21:38:47+00:00 2024-11-03T21:38:47+00:00 Jubilee Young workingjubilee@gmail.com 2024-11-03T02:32:52+00:00 urn:sha1:bbd18e29da5d06db8e2c4d6c8111118aa7efec24 2024-10-29T21:56:00+00:00 Jubilee Young workingjubilee@gmail.com 2024-10-29T20:37:26+00:00 urn:sha1:7086dd83cca1cf694c7bd171efbf262fa8ffb4aa The initial naming of "Abi" was an awful mistake, conveying wrong ideas about how psABIs worked and even more about what the enum meant. It was only meant to represent the way the value would be described to a codegen backend as it was lowered to that intermediate representation. It was never meant to mean anything about the actual psABI handling! The conflation is because LLVM typically will associate a certain form with a certain ABI, but even that does not hold when the special cases that actually exist arise, plus the IR annotations that modify the ABI. Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename `BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to the persistent misunderstandings, this too is now incorrect: - Scattered ABI-relevant code is entangled with BackendRepr - We do not always pre-compute a correct BackendRepr that reflects how we "actually" want this value to be handled, so we leave the backend interface to also inject various special-cases here - In some cases `BackendRepr::Memory` is a "real" aggregate, but in others it is in fact using memory, and in some cases it is a scalar! Our rustc-to-backend lowering code handles this sort of thing right now. That will eventually be addressed by lifting duplicated lowering code to either rustc_codegen_ssa or rustc_target as appropriate. 2024-10-28T16:58:30+00:00 Jubilee Young workingjubilee@gmail.com 2024-10-28T04:34:49+00:00 urn:sha1:88a9edc091fad78a8e3784fe656e369417bb6acc This reduces the need of the compiler to peek on the fields of LayoutS. 2024-10-01T19:45:35+00:00 Ralf Jung post@ralfj.de 2024-09-29T09:53:23+00:00 urn:sha1:c4ce8c114b06840c3521a189ee44958b713fb33a 2024-09-22T23:11:29+00:00 Michael Goulet michael@errs.io 2024-09-22T23:05:04+00:00 urn:sha1:c682aa162b0d41e21cc6748f4fecfe01efb69d1f 2024-09-08T14:53:22+00:00 Ralf Jung post@ralfj.de 2024-08-28T15:39:09+00:00 urn:sha1:fa60ea7d388890169683ad397aba1edf4979738a 2024-07-28T22:26:52+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-07-28T22:13:50+00:00 urn:sha1:84ac80f1921afc243d71fd0caaa4f2838c294102 The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options. 2024-07-02T03:25:31+00:00 hattizai hattizai@gmail.com 2024-07-02T03:25:31+00:00 urn:sha1:ada9fda7c38b1be39b4e8273ee6af150985df064 2024-06-14T21:11:08+00:00 Jack Wrenn jack@wrenn.fyi 2024-06-14T17:02:07+00:00 urn:sha1:df1d6168f4deef4954f3b74a23fe1e923d9b95b6 Previously, `Tree::from_enum`'s implementation branched into three disjoint cases: 1. enums that uninhabited 2. enums for which all but one variant is uninhabited 3. enums with multiple inhabited variants This branching (incorrectly) did not differentiate between variantful and variantless uninhabited enums. In both cases, we assumed (and asserted) that uninhabited enums are zero-sized types. This assumption is false for enums like: enum Uninhabited { A(!, u128) } ...which, currently, has the same size as `u128`. This faulty assumption manifested as the ICE reported in #126460. In this PR, we revise the first case of `Tree::from_enum` to consider only the narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts are described with `Variants::Single { index }`, are special in their layouts otherwise resemble the `!` type and cannot be descended into like typical enums. This first case captures uninhabited enums like: enum Uninhabited { A(!, !), B(!) } The second case is revised to consider the broader category of "enums that defer their layout to one of their variants"; i.e., enums whose layouts are described with `Variants::Single { index }` and that do have a variant at `index`. This second case captures uninhabited enums that are not ZSTs, like: enum Uninhabited { A(!, u128) } ...which represent their variants with `Variants::Single`. Finally, the third case is revised to cover the broader category of "enums with multiple variants", which captures uninhabited, non-ZST enums like: enum Uninhabited { A(u8, !), B(!, u32) } ...which represent their variants with `Variants::Multiple`. This PR also adds a comment requested by RalfJung in his review of #126358 to `compiler/rustc_const_eval/src/interpret/discriminant.rs`. Fixes #126460 2024-06-13T01:38:51+00:00 Jack Wrenn jack@wrenn.fyi 2024-06-12T22:07:37+00:00 urn:sha1:fb662f2126b026c91ddbc17ac3bdb8bd2bf575c5 Previously, the implementation of `Tree::from_enum` incorrectly treated enums with `Variants::Single` and `Variants::Multiple` identically. This is incorrect for `Variants::Single` enums, which delegate their layout to that of a variant with a particular index (or no variant at all if the enum is empty). This flaw manifested first as an ICE. `Tree::from_enum` attempted to compute the tag of variants other than the one at `Variants::Single`'s `index`, and fell afoul of a sanity-checking assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`. This assertion is non-load-bearing, and can be removed; the routine its in is well-behaved even without it. With the assertion removed, the proximate issue becomes apparent: calling `Tree::from_variant` on a variant that does not exist is ill-defined. A sanity check the given variant has `FieldShapes::Arbitrary` fails, and the analysis is (correctly) aborted with `Err::NotYetSupported`. This commit corrects this chain of failures by ensuring that `Tree::from_variant` is not called on variants that are, as far as layout is concerned, nonexistent. Specifically, the implementation of `Tree::from_enum` is now partitioned into three cases: 1. enums that are uninhabited 2. enums for which all but one variant is uninhabited 3. enums with multiple inhabited variants `Tree::from_variant` is now only invoked in the third case. In the first case, `Tree::uninhabited()` is produced. In the second case, the layout is delegated to `Variants::Single`'s index. Fixes #125811