rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2025-07-03	Allow all MIR `Aggregate`s to take the operand path (if layout permits)	Scott McMurray	-2/+4

2025-04-07	mitigate MSVC unsoundness by not emitting alignment attributes on win32-msvc ↵	Ralf Jung	-1/+3
	targets also mention the MSVC alignment issue in platform-support.md
2024-05-31	Run rustfmt on `tests/codegen/`.	Nicholas Nethercote	-7/+7
	Except for `simd-intrinsic/`, which has a lot of files containing multiple types like `u8x64` which really are better when hand-formatted. There is a surprising amount of two-space indenting in this directory. Non-trivial changes: - `rustfmt::skip` needed in `debug-column.rs` to preserve meaning of the test. - `rustfmt::skip` used in a few places where hand-formatting read more nicely: `enum/enum-match.rs` - Line number adjustments needed for the expected output of `debug-column.rs` and `coroutine-debug.rs`.
2024-04-11	use [N x i8] for alloca types	Erik Desjardins	-4/+4

2024-03-05	use [N x i8] for byval/sret types	Erik Desjardins	-4/+0
	This avoids depending on LLVM's struct types to determine the size of the byval/sret slot.
2024-02-26	always use gep inbounds i8 (ptradd) for field offsets	Erik Desjardins	-1/+0

2024-02-22	[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives	许杰友 Jieyou Xu (Joe)	-1/+1

2023-12-15	Separate immediate and in-memory ScalarPair representation	Nikita Popov	-1/+1
	Currently, we assume that ScalarPair is always represented using a two-element struct, both as an immediate value and when stored in memory. This currently works fairly well, but runs into problems with https://github.com/rust-lang/rust/pull/116672, where a ScalarPair involving an i128 type can no longer be represented as a two-element struct in memory. For example, the tuple `(i32, i128)` needs to be represented in-memory as `{ i32, [3 x i32], i128 }` to satisfy alignment requirement. Using `{ i32, i128 }` instead will result in the second element being stored at the wrong offset (prior to LLVM 18). Resolve this issue by no longer requiring that the immediate and in-memory type for ScalarPair are the same. The in-memory type will now look the same as for normal struct types (and will include padding filler and similar), while the immediate type stays a simple two-element struct type. This also means that booleans in immediate ScalarPair are now represented as i1 rather than i8, just like we do everywhere else. The core change here is to llvm_type (which now treats ScalarPair as a normal struct) and immediate_llvm_type (which returns the two-element struct that llvm_type used to produce). The rest is fixing things up to no longer assume these are the same. In particular, this switches places that try to get pointers to the ScalarPair elements to use byte-geps instead of struct-geps.
2023-07-27	CHECK only for opaque ptr	Josh Stone	-2/+2

2023-01-11	Move /src/test to /tests	Albert Larsan	-0/+71