Delete stuff that should have been deleted in 1.12.1 #37451
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bump boostrap compilers
Stabilized
* `Cell::as_ptr`
* `RefCell::as_ptr`
* `IpAddr::is_{unspecified,loopback,multicast}`
* `Ipv6Addr::octets`
* `LinkedList::contains`
* `VecDeque::contains`
* `ExitStatusExt::from_raw` - both on Unix and Windows
* `Receiver::recv_timeout`
* `RecvTimeoutError`
* `BinaryHeap::peek_mut`
* `PeekMut`
* `iter::Product`
* `iter::Sum`
* `OccupiedEntry::remove_entry`
* `VacantEntry::into_key`
Deprecated
* `Cell::as_unsafe_cell`
* `RefCell::as_unsafe_cell`
* `OccupiedEntry::remove_pair`
Closes rust-lang#27708
cc rust-lang#27709
Closes rust-lang#32313
Closes rust-lang#32630
Closes rust-lang#32713
Closes rust-lang#34029
Closes rust-lang#34392
Closes rust-lang#34285
Closes rust-lang#34529
Backport PRs to beta
This fixes rust-lang#35849, a regression introduced by the typeck refactoring around TyNever/!.
The memrchr fallback did not compute the offset correctly. It was
intentioned to land on usize-aligned addresses but did not.
This was suspected to resulted in a crash on ARMv7 platform!
This bug affected non-linux platforms.
I think like this, if we have a slice with pointer `ptr` and length
`len`, we want to find the last usize-aligned offset in the slice.
The correct computation should be:
For example if ptr = 1 and len = 6, and size_of::<usize>() is 4:
[ x x x x x x ]
1 2 3 4 5 6
^-- last aligned address at offset 3 from the start.
The last aligned address is ptr + len - (ptr + len) % usize_size.
Compute offset from the start as:
offset = len - (ptr + len) % usize_size = 6 - (1 + 6) % 4 = 6 - 3 = 3.
I believe the function's return value was always correct previously, if
the platform supported unaligned addresses.
This makes the critical calculation easier to understand.
Backport PRs to beta
Bump beta to .3
We were treating an associated type as unsized even when the concrete instantiation was actually sized. Fix is to normalize before checking if it is sized.
Beta backports
Go back on half the specialization, the part that changed the Zip
struct's fields themselves depending on the types of the iterators.
This means that the Zip iterator will always carry two usize fields,
which are unused. If a whole for loop using a .zip() iterator is
inlined, these are simply removed and have no effect.
The same improvement for Zip of for example slice iterators remain, and
they still optimize well. However, like when the specialization of zip
was merged, the compiler is still very sensistive to the exact context.
For example this code only autovectorizes if the function is used, not
if the code in zip_sum_i32 is inserted inline it was called:
```
fn zip_sum_i32(xs: &[i32], ys: &[i32]) -> i32 {
let mut s = 0;
for (&x, &y) in xs.iter().zip(ys) {
s += x * y;
}
s
}
fn zipdot_i32_default_zip(b: &mut test::Bencher)
{
let xs = vec![1; 1024];
let ys = vec![1; 1024];
b.iter(|| {
zip_sum_i32(&xs, &ys)
})
}
```
Include a test that checks that Zip<T, U> is covariant w.r.t. T and U.
Beta backports
Bump to beta.4
Fix build error
[beta] Update rust-installer. Fixes rust-lang#35840
[beta] Fix optimization regressions for operations on [x; n]-initialized arr…
This reverts commit ac73335.
Remove reverted feature from relnotes
The collector was asserting a total absence of projections, but some projections are expected, even in trans: in particular, projections containing higher-ranked regions, which we don't currently normalize.
Work around LLVM bug. cc rust-lang#36856
…es in GetCaseResults"
that made no sense (see test), and was incompatible with borrowck. Fixes rust-lang#36936.
…or the individual pieces.
[stable] Backports for 1.12.1
Otherwise 1.12.1 FTBFS on Debian when trying to bootstrap from 1.12.0.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
|
|
Instructions for how to bootstrap from 1.12.0 are here https://users.rust-lang.org/t/bootstrapping-1-12-1-from-1-12-0/7715 |
|
r? @brson |
|
☔ The latest upstream changes (presumably #37641) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Obsolete, we're applying the above bootstrapping-1-12-1-from-1-12-0 patch dynamically now in Debian. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Otherwise 1.12.1 FTBFS on Debian when trying to bootstrap from 1.12.0.
This is only really useful if you guys release a 1.12.2, but you might want to think about how to prevent similar things in the future...