https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.77.2 2024-01-26T13:43:30+00:00 2024-01-26T13:43:30+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-01-26T13:43:30+00:00 urn:sha1:772e80a650fc22c2b0e419698833960cc558d896 Remove special-case handling of `vec.split_off(0)` #76682 added special handling to `Vec::split_off` for the case where `at == 0`. Instead of copying the vector's contents into a freshly-allocated vector and returning it, the special-case code steals the old vector's allocation, and replaces it with a new (empty) buffer with the same capacity. That eliminates the need to copy the existing elements, but comes at a surprising cost, as seen in #119913. The returned vector's capacity is no longer determined by the size of its contents (as would be expected for a freshly-allocated vector), and instead uses the full capacity of the old vector. In cases where the capacity is large but the size is small, that results in a much larger capacity than would be expected from reading the documentation of `split_off`. This is especially bad when `split_off` is called in a loop (to recycle a buffer), and the returned vectors have a wide variety of lengths. I believe it's better to remove the special-case code, and treat `at == 0` just like any other value: - The current documentation states that `split_off` returns a “newly allocated vector”, which is not actually true in the current implementation when `at == 0`. - If the value of `at` could be non-zero at runtime, then the caller has already agreed to the cost of a full memcpy of the taken elements in the general case. Avoiding that copy would be nice if it were close to free, but the different handling of capacity means that it is not. - If the caller specifically wants to avoid copying in the case where `at == 0`, they can easily implement that behaviour themselves using `mem::replace`. Fixes #119913. 2024-01-13T06:21:54+00:00 Zalathar Zalathar@users.noreply.github.com 2024-01-13T06:12:15+00:00 urn:sha1:a655558b380bf689f806e45fc896b7e6ba739cb7 2024-01-11T12:04:48+00:00 klensy klensy@users.noreply.github.com 2024-01-11T12:04:48+00:00 urn:sha1:aa696c5a228a2c9730227eb5a0e99fb9d85eb61d 2024-01-02T20:34:37+00:00 Jake Goulding jake.goulding@gmail.com 2023-12-27T23:03:23+00:00 urn:sha1:5772818dc8f4c5a0fec1f5b35b33e85764dcd4f4 2023-12-11T14:33:16+00:00 bors bors@rust-lang.org 2023-12-11T14:33:16+00:00 urn:sha1:8a3765582cb83733f8c344062729df0175409488 Add lint against ambiguous wide pointer comparisons This PR is the resolution of https://github.com/rust-lang/rust/issues/106447 decided in https://github.com/rust-lang/rust/issues/117717 by T-lang. ## `ambiguous_wide_pointer_comparisons` *warn-by-default* The `ambiguous_wide_pointer_comparisons` lint checks comparison of `*const/*mut ?Sized` as the operands. ### Example ```rust let ab = (A, B); let a = &ab.0 as *const dyn T; let b = &ab.1 as *const dyn T; let _ = a == b; ``` ### Explanation The comparison includes metadata which may not be expected. ------- This PR also drops `clippy::vtable_address_comparisons` which is superseded by this one. ~~One thing: is the current naming right? `invalid` seems a bit too much.~~ Fixes https://github.com/rust-lang/rust/issues/117717 2023-12-10T02:56:22+00:00 surechen chenshuo17@huawei.com 2023-11-10T02:11:24+00:00 urn:sha1:40ae34194c586eea3614d3216322053d2e8e7b37 detects redundant imports that can be eliminated. for #117772 : In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR. 2023-12-06T08:45:11+00:00 bors bors@rust-lang.org 2023-12-06T08:45:11+00:00 urn:sha1:15bb3e204ad5fbaf53b2b26e47247f3cbbba63f1 Fix in-place collect not reallocating when necessary Regression introduced in https://github.com/rust-lang/rust/pull/110353. This was [caught by miri](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Cron.20Job.20Failure.20.28miri-test-libstd.2C.202023-11.29/near/404764617) r? `@saethlin` 2023-12-06T08:03:48+00:00 Urgau urgau@numericable.fr 2023-11-09T17:13:52+00:00 urn:sha1:5e1bfb538f195eeac02034c0779f42d34b0e869e 2023-12-05T19:52:41+00:00 Michael Goulet michael@errs.io 2023-12-05T19:52:41+00:00 urn:sha1:19bf7495605962df2b0bfa96382a4f717f63b0c3 Add support for making lib features internal We have the notion of an "internal" lang feature: a feature that is never intended to be stabilized, and using which can cause ICEs and other issues without that being considered a bug. This extends that idea to lib features as well. It is an alternative to https://github.com/rust-lang/rust/pull/115623: instead of using an attribute to declare lib features internal, we simply do this based on the name. Everything ending in `_internals` or `_internal` is considered internal. Then we rename `core_intrinsics` to `core_intrinsics_internal`, which fixes https://github.com/rust-lang/rust/issues/115597. 2023-12-05T19:09:22+00:00 The 8472 git@infinite-source.de 2023-11-29T21:24:16+00:00 urn:sha1:13a843ebcbe536257a8442bf5c26b227d1c2f7c9