jiebi/CodeConvo huggingface dataset:
Code change:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.

Related discussion:
text: <ins> error[E0283]: type annotations needed --> $DIR/issue-34979.rs:6:13 | LL | trait Foo {} | --------- required by this bound in `Foo` ... LL |     &'a (): Foo, |             ^^^ cannot infer type for reference `&'a ()` | = note: cannot satisfy `&'a (): Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>
Code change:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.

Related discussion:
text: fn consume(&mut self, amt: usize) { self.pos += amt as u64; } } <ins> // Non-resizing write implementation fn slice_write(pos_mut: &mut u64, slice: &mut [u8], buf: &[u8]) -> io::Result<usize> { let pos = cmp::min(*pos_mut, slice.len() as u64); let amt = (&mut slice[(pos as usize)..]).write(buf)?; *pos_mut += amt as u64; Ok(amt) } // Resizing write implementation fn vec_write(pos_mut: &mut u64, vec: &mut Vec<u8>, buf: &[u8]) -> io::Result<usize> { let pos: usize = (*pos_mut).try_into().map_err(|_| { Error::new(ErrorKind::InvalidInput, "cursor position exceeds maximum possible vector length") })?; // Make sure the internal buffer is as least as big as where we // currently are let len = vec.len(); if len < pos { // use `resize` so that the zero filling is as efficient as possible vec.resize(pos, 0); } // Figure out what bytes will be used to overwrite what's currently // there (left), and what will be appended on the end (right) { let space = vec.len() - pos; let (left, right) = buf.split_at(cmp::min(space, buf.len())); vec[pos..pos + left.len()].copy_from_slice(left); vec.extend_from_slice(right); } // Bump us forward *pos_mut = (pos + buf.len()) as u64; Ok(buf.len()) } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a> Write for Cursor<&'a mut [u8]> { #[inline] <del> fn write(&mut self, data: &[u8]) -> io::Result<usize> { let pos = cmp::min(self.pos, self.inner.len() as u64); let amt = (&mut self.inner[(pos as usize)..]).write(data)?; self.pos += amt as u64; Ok(amt) </del> <ins> fn write(&mut self, buf: &[u8]) -> io::Result<usize> { slice_write(&mut self.pos, self.inner, buf) } fn flush(&mut self) -> io::Result<()> { Ok(()) } } #[unstable(feature = "cursor_mut_vec", issue = "30132")] impl<'a> Write for Cursor<&'a mut Vec<u8>> { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { vec_write(&mut self.pos, self.inner, buf) </ins> } fn flush(&mut self) -> io::Result<()> { Ok(()) } }
Code change:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] impl Write for Cursor<Vec<u8>> { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> let pos: usize = self.position().try_into().map_err(|_| { Error::new(ErrorKind::InvalidInput, "cursor position exceeds maximum possible vector length") })?; // Make sure the internal buffer is as least as big as where we // currently are let len = self.inner.len(); if len < pos { // use `resize` so that the zero filling is as efficient as possible self.inner.resize(pos, 0); } // Figure out what bytes will be used to overwrite what's currently // there (left), and what will be appended on the end (right) { let space = self.inner.len() - pos; let (left, right) = buf.split_at(cmp::min(space, buf.len())); self.inner[pos..pos + left.len()].copy_from_slice(left); self.inner.extend_from_slice(right); } // Bump us forward self.set_position((pos + buf.len()) as u64); Ok(buf.len()) </del> <ins> vec_write(&mut self.pos, &mut self.inner, buf) </ins> } fn flush(&mut self) -> io::Result<()> { Ok(()) } }
Code change:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.

Related discussion:
text: impl Write for Cursor<Box<[u8]>> { #[inline] fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> let pos = cmp::min(self.pos, self.inner.len() as u64); let amt = (&mut self.inner[(pos as usize)..]).write(buf)?; self.pos += amt as u64; Ok(amt) </del> <ins> slice_write(&mut self.pos, &mut self.inner, buf) </ins> } fn flush(&mut self) -> io::Result<()> { Ok(()) } }
Code change:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.

Related discussion:
text: } #[test] <ins> fn test_mem_mut_writer() { let mut vec = Vec::new(); let mut writer = Cursor::new(&mut vec); assert_eq!(writer.write(&[0]).unwrap(), 1); assert_eq!(writer.write(&[1, 2, 3]).unwrap(), 3); assert_eq!(writer.write(&[4, 5, 6, 7]).unwrap(), 4); let b: &[_] = &[0, 1, 2, 3, 4, 5, 6, 7]; assert_eq!(&writer.get_ref()[..], b); } #[test] </ins> fn test_box_slice_writer() { let mut writer = Cursor::new(vec![0u8; 9].into_boxed_slice()); assert_eq!(writer.position(), 0);
Code change:
When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.

Related discussion:
text: ``` You'll notice that you don't need a `fn main()` or anything here. `rustdoc` will <del> automatically add a `main()` wrapper around your code, and in the right place. For example: </del> <ins> automatically add a `main()` wrapper around your code, using heuristics to attempt to put it in the right place. For example: </ins> ```rust /// ```
Code change:
When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.

Related discussion:
text: `unused_attributes`, and `dead_code`. Small examples often trigger these lints. 3. If the example does not contain `extern crate`, then `extern crate <del> <mycrate>;` is inserted. 2. Finally, if the example does not contain `fn main`, the remainder of the text is wrapped in `fn main() { your_code }` Sometimes, this isn't enough, though. For example, all of these code samples </del> <ins> <mycrate>;` is inserted (note the lack of `#[macro_use]`). 4. Finally, if the example does not contain `fn main`, the remainder of the text is wrapped in `fn main() { your_code }`. This generated `fn main` can be a problem! If you have `extern crate` or a `mod` statements in the example code that are referred to by `use` statements, they will fail to resolve unless you include at least `fn main() {}` to inhibit step 4. `#[macro_use] extern crate` also does not work except at the crate root, so when testing macros an explicit `main` is always required. It doesn't have to clutter up your docs, though -- keep reading! Sometimes this algorithm isn't enough, though. For example, all of these code samples </ins> with `///` we've been talking about? The raw text: ```text
Code change:
When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.

Related discussion:
text: You’ll note three things: we need to add our own `extern crate` line, so that we can add the `#[macro_use]` attribute. Second, we’ll need to add our own <del> `main()` as well. Finally, a judicious use of `#` to comment out those two things, so they don’t show up in the output. </del> <ins> `main()` as well (for reasons discussed above). Finally, a judicious use of `#` to comment out those two things, so they don’t show up in the output. </ins> Another case where the use of `#` is handy is when you want to ignore error handling. Lets say you want the following,
Code change:
As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .

Related discussion:
text: // the merge has confused the heck out of josh in the past. // We pass `--no-verify` to avoid running git hooks like `./miri fmt` that could in turn // trigger auto-actions. <del> sh.write_file("rust-version", &commit)?; </del> <ins> sh.write_file("rust-version", format!("{commit}n"))?; </ins> const PREPARING_COMMIT_MESSAGE: &str = "Preparing for merge from rustc"; cmd!(sh, "git commit rust-version --no-verify -m {PREPARING_COMMIT_MESSAGE}") .run()
Code change:
As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .

Related discussion:
text: // interleaving, but wether UB happens can depend on whether a write occurs in the // future... let is_write = new_perm.initial_state.is_active() <del> || (new_perm.initial_state.is_resrved() && new_perm.protector.is_some()); </del> <ins> || (new_perm.initial_state.is_reserved() && new_perm.protector.is_some()); </ins> if is_write { // Need to get mutable access to alloc_extra. // (Cannot always do this as we can do read-only reborrowing on read-only allocations.)
Code change:
As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .

Related discussion:
text: matches!(self.inner, Active) } <del> pub fn is_resrved(self) -> bool { </del> <ins> pub fn is_reserved(self) -> bool { </ins> matches!(self.inner, Reserved { .. }) }
Code change:
As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .

Related discussion:
text: /// in an existing allocation, then returns Err containing the position /// where such allocation should be inserted fn find_offset(&self, offset: Size) -> Result<Position, Position> { <del> // We do a binary search. let mut left = 0usize; // inclusive let mut right = self.v.len(); // exclusive loop { if left == right { // No element contains the given offset. But the // position is where such element should be placed at. return Err(left); } let candidate = left.checked_add(right).unwrap() / 2; let elem = &self.v[candidate]; </del> <ins> self.v.binary_search_by(|elem| -> std::cmp::Ordering { </ins> if offset < elem.range.start { // We are too far right (offset is further left). <del> debug_assert!(candidate < right); // we are making progress right = candidate; </del> <ins> std::cmp::Ordering::Greater </ins> } else if offset >= elem.range.end() { // We are too far left (offset is further right). <del> debug_assert!(candidate >= left); // we are making progress left = candidate + 1; </del> <ins> std::cmp::Ordering::Less </ins> } else { // This is it! <del> return Ok(candidate); </del> <ins> std::cmp::Ordering::Equal </ins> } <del> } </del> <ins> }) </ins> } /// Determines whether a given access on `range` overlaps with
Code change:
As a newbie, I made the mistake that can be witnessed with the field in . The way this happened is that I vaguely remembered that you can't use when specifying the fields of and to make sure, I looked up the struct chapter in the book. Sure enough, it said "Mutability is a property of the binding, not of the structure itself." Now, as a newbie, I thought this forbade in field definitions altogether even though it only forbids to the left of the colon and you can still have as the type to the right of the colon. It would be nice if this was briefly clarified for the benefit of newbies looking stuff up piecemeal and not properly thinking about stuff in the context of what has previously been said in an earlier chapter.
:+1:

Related discussion:
text: } ``` <ins> Your structure can still contain `&mut` pointers, which will let you do some kinds of mutation: ```rust struct Point { x: i32, y: i32, } struct PointRef<'a> { x: &'a mut i32, y: &'a mut i32, } fn main() { let mut point = Point { x: 0, y: 0 }; { let r = PointRef { x: &mut point.x, y: &mut point.y }; *r.x = 5; *r.y = 6; } assert_eq!(5, point.x); assert_eq!(6, point.y); } ``` </ins> # Update syntax A `struct` can include `..` to indicate that you want to use a copy of some
Code change:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

Related discussion:
text: // These items live in the type namespace. ItemTy(..) => { <del> let parent_link = ModuleParentLink(parent, name); </del> let def = Def::TyAlias(self.ast_map.local_def_id(item.id)); <del> let module = self.new_module(parent_link, Some(def), false, is_public); self.define(parent, name, TypeNS, (module, sp)); </del> <ins> self.define(parent, name, TypeNS, (def, sp, modifiers)); </ins> parent }
Code change:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

Related discussion:
text: } match def { <del> Def::Mod(_) | Def::ForeignMod(_) | Def::Enum(..) | Def::TyAlias(..) => { </del> <ins> Def::Mod(_) | Def::ForeignMod(_) | Def::Enum(..) => { </ins> debug!("(building reduced graph for external crate) building module {} {}", final_ident, is_public);