https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.86.0 2024-12-18T02:38:53+00:00 2024-12-18T02:38:53+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-12-12T23:29:23+00:00 urn:sha1:2620eb42d72d24baa1ca1056a769862b92c85f7f `rustc_span::symbol` defines some things that are re-exported from `rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some closely related things such as `Ident` and `kw`. So you can do `use rustc_span::{Symbol, sym}` but you have to do `use rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good reason. This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`, and changes many `rustc_span::symbol::` qualifiers in `compiler/` to `rustc_span::`. This is a 200+ net line of code reduction, mostly because many files with two `use rustc_span` items can be reduced to one. 2024-12-15T18:18:46+00:00 Jonathan Dönszelmann jonathan@donsz.nl 2024-10-16T23:14:01+00:00 urn:sha1:d50c0a5480257cbac33b312cb633777f3d2b2483 2024-11-18T09:38:56+00:00 lcnr rust@lcnr.de 2024-11-15T12:53:31+00:00 urn:sha1:9cba14b95bb07a5b31ed1aac2bf4eadd248232da the behavior of the type system not only depends on the current assumptions, but also the currentnphase of the compiler. This is mostly necessary as we need to decide whether and how to reveal opaque types. We track this via the `TypingMode`. 2024-10-30T21:01:37+00:00 Jubilee workingjubilee@gmail.com 2024-10-30T21:01:37+00:00 urn:sha1:847b6fe6b0c18c282fd13406ab48f58a5b4b2149 Rename `rustc_abi::Abi` to `BackendRepr` Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights. Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings. 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-29T16:01:24+00:00 lcnr rust@lcnr.de 2024-10-17T22:28:43+00:00 urn:sha1:f51ec110a714fea09105586b26c7f8e6a2a57018 2024-10-28T04:10:58+00:00 Jubilee Young workingjubilee@gmail.com 2024-10-28T03:38:33+00:00 urn:sha1:4839d6e6e51f29c6bd9b581df520a8f1a6d278b9 Depend on rustc_abi in compiler crates that use it indirectly but have not yet taken on that dependency, and are not entangled in my other PRs. This leaves an "excise rustc_target" step after the dust settles. 2024-10-23T08:14:41+00:00 Ralf Jung post@ralfj.de 2024-10-09T07:01:57+00:00 urn:sha1:ad3991d30382676f987a38243b3097d880b9033a 2024-09-22T23:11:29+00:00 Michael Goulet michael@errs.io 2024-09-22T23:05:04+00:00 urn:sha1:c682aa162b0d41e21cc6748f4fecfe01efb69d1f 2024-09-18T15:49:43+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-09-18T15:49:43+00:00 urn:sha1:21313d7947d435217a916c0d71999a077b90c979 Cleanup codegen traits The traits governing codegen are quite complicated and hard to follow. This PR cleans them up a bit. r? `@bjorn3`