https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.77.2 2024-02-15T18:54:29+00:00 2024-02-15T18:54:29+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2024-02-09T16:11:37+00:00 urn:sha1:131e1fc968dfff4f8d2a986b4200089a92d48dc4 (cherry picked from commit 83f3bc42714250633cacadcde8b15da28bf443f0) 2024-01-25T14:01:33+00:00 clubby789 jamie@hill-daniel.co.uk 2024-01-14T20:08:47+00:00 urn:sha1:fd29f74ff8d787f707a40bc5dbcd8f7827100f5e 2024-01-24T23:36:57+00:00 Josh Stone jistone@redhat.com 2024-01-24T23:36:57+00:00 urn:sha1:8f3af4c6e21feb3cada901ea6f41f198b0f0e74a 2024-01-22T13:08:19+00:00 bors bors@rust-lang.org 2024-01-22T13:08:19+00:00 urn:sha1:30662530506ed29ea29191798cb2ab8aa1249023 Pack u128 in the compiler to mitigate new alignment This is based on #116672, adding a new `#[repr(packed(8))]` wrapper on `u128` to avoid changing any of the compiler's size assertions. This is needed in two places: * `SwitchTargets`, otherwise its `SmallVec<[u128; 1]>` gets padded up to 32 bytes. * `LitKind::Int`, so that entire `enum` can stay 24 bytes. * This change definitely has far-reaching effects though, since it's public. 2024-01-20T13:18:33+00:00 bors bors@rust-lang.org 2024-01-20T13:18:33+00:00 urn:sha1:6745c6000aa037c14bf4359c5cb56d4c657bfe3c Remove `OneThread` This removes `OneThread` by switching `incr_comp_session` over to `RwLock`. 2024-01-20T04:10:38+00:00 Josh Stone jistone@redhat.com 2024-01-17T23:39:45+00:00 urn:sha1:cb7d863e742ae3782174db2acf57310cd1b27561 2024-01-19T04:43:17+00:00 bors bors@rust-lang.org 2024-01-19T04:43:17+00:00 urn:sha1:1bd42be8cb707aadaf2068d5ac186154970c4d80 Use UnhashMap for a few more maps This avoids a few cases of hashing data that's already hashed. cc https://github.com/rust-lang/rust/issues/56308 2024-01-18T18:54:54+00:00 bors bors@rust-lang.org 2024-01-18T18:54:54+00:00 urn:sha1:25f8d01fd8bda339612d0c0a8844173a09205f7c [rustc_data_structures] Use partition_point to find slice range end. This PR uses approach introduced in https://github.com/rust-lang/rust/pull/114152 to find the end of the range. It's much easier to understand and reason about invariants of such implementation. Technically it's possible to make it even shorter by returning `&[start..end]` unconditionally because even if searched item is not present in the slice, `start` and `end` would point at the same index, so the range would be empty. The reason I decided not to use this shorter implementation is because it would involve more comparisons in case there are no elements in the slice with key equal to `key`. Also, not that it matters much, but this implementation also improves perf according to the benchmark below: https://gist.github.com/ttsugriy/63c0ed39ae132b131931fa1f8a3dea55 The results on my M1 macbook air are: ``` Running benches/bin_search_slice_benchmark.rs (target/release/deps/bin_search_slice_benchmark-90fa6d68c3bd1298) Benchmarking multiply add/binary_search_slice: Collecting 100 samples in estimated 5.0002 s (1 multiply add/binary_search_slice time: [44.719 ns 44.918 ns 45.158 ns] No change in performance detected. Found 3 outliers among 100 measurements (3.00%) 1 (1.00%) high mild 2 (2.00%) high severe Benchmarking multiply add/binary_search_slice_new: Collecting 100 samples in estimated 5.0001 multiply add/binary_search_slice_new time: [36.955 ns 37.060 ns 37.221 ns] No change in performance detected. Found 7 outliers among 100 measurements (7.00%) 3 (3.00%) high mild 4 (4.00%) high severe ``` 2024-01-18T02:30:05+00:00 John Kåre Alsaker john.kare.alsaker@gmail.com 2023-09-26T20:34:09+00:00 urn:sha1:63446d00ee2005125b1e4a7c3f00547101065709 2024-01-17T22:09:55+00:00 Mark Rousskov mark.simulacrum@gmail.com 2024-01-17T22:09:04+00:00 urn:sha1:510fcd318b61d0e45165cdb0de880ee2f4f9cde2 This avoids hashing data that's already hashed.