-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test on custom type with std::io::Read impl fails on 1.76.0 #123700
Comments
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 bisected with cargo-bisect-rustc v0.6.8Host triple: aarch64-unknown-linux-gnu cargo bisect-rustc --start=1.75.0 --end=1.77.1 -- test |
@jieyouxu just tested with 1.76.0 and the regression was there so updated the comment and title |
This is failing with a The false branch in that match is kind of sus anyway. Turning a single Edit: Oh I see it's a bisection result. I'll take another look. |
I did some testing for what types of // 1.75.0 panic, 1.76.0 panic
let mut v = Vec::new();
// 1.75.0 panic, 1.76.0 panic
let mut v = Vec::with_capacity(7);
// 1.75.0 NO panic, 1.76.0 panic
let mut v = Vec::with_capacity(8); Looking at these results I would guess that the old behavior was actually wrong and that it got fixed. |
@konsti219 looks like initialisation is needed now e.g like however |
Ok, I had a closer look at the code. The issue is with both the A) The test assumes that B) The read function does not handle large buffers getting passed in properly. let len = buf.len();
let to_end = (self.first_len - self.pos) as usize;
match to_end >= len {
true => self.first.read(buf)?,
false => {
let mut first = vec![0; to_end];
let mut second = vec![0; len - to_end];
self.first.read_exact(&mut first)?;
sec.read_exact(&mut second)?;
first.append(&mut second);
first.as_slice().read(buf)? With So the change in the read_to_end impl merely uncovered preexisting bug in your code. |
thanks so much @the8472 - so it was that buf is now not always guaranteed to match the vec capacity which also exposed bad parity with large buffers changing to this now allows passing the test :) let len = buf.len() as u64;
let to_end = self.first_len - self.pos;
match to_end >= len {
true => self.first.read(buf)?,
false => {
let mut first = vec![0; to_end as usize];
let excess = len - to_end;
let mut second = vec![
0;
match excess > self.second_len {
true => self.second_len,
false => excess,
} as usize
];
self.first.read_exact(&mut first)?;
sec.read_exact(&mut second)?;
first.append(&mut second);
first.as_slice().read(buf)?
}
} thank you so much - this turned out to be an improvement rather than a regression |
the data structure
the tests:
I expected to see this happen: the tests should pass
Instead, this happened: the read test failed with an end of file error
Version it worked on
It most recently worked on: Rust 1.75.0
Version with regression
Rust 1.76.0
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: