jiebi/CodeConvo huggingface dataset:
Code change:
We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Related discussion:
text: tcx.sess.bug(&format!("using operand temp {:?} as lvalue", lvalue)), }, mir::Lvalue::Arg(index) => self.args[index as usize], <del> mir::Lvalue::Static(_def_id) => unimplemented!(), </del> <ins> mir::Lvalue::Static(def_id) => { let const_ty = self.mir.lvalue_ty(tcx, lvalue); LvalueRef::new(common::get_static_val(ccx, def_id, const_ty.to_ty(tcx)), const_ty) }, </ins> mir::Lvalue::ReturnPointer => { let return_ty = bcx.monomorphize(&self.mir.return_ty); let llval = fcx.get_ret_slot(bcx, return_ty, "return");
Code change:
The presence in a Rust source file of unusual but useful kinds of whitespace, such as ASCII 0x0C (form feed), leads to the following error: I have a specific use case for form-feeds in source files. But I think in general it is nice to ignore the same whitespace that every other programming language and file format ignores; it lessens confusion for people coming from other languages and backgrounds. My specific use case is the long-standing, but somewhat uncommon use of the form-feed character (which semantically is a separator between pages of text) as a way to group together especially closely related functions or blocks in a file of source code. Text editors or IDEs such as vim, Emacs or XCode provide convenience features to display these form-feeds in aesthetically pleasing way, move between form-feed-delimited pages, and restrict editing to one form-feed-delimited page at a time. It's just a simple convenience feature, but it would really be nice to support it.
+1, I also use this feature and was disappointed when I found Rust didn't treat it as whitespace.
Looks like a fairly simple change could be made to the lexer so it uses instead of limiting to . The only think I can think of is that the function in has been around since before we had a better function and nobody has changed it since then.
/cc , do we want to accept all kinds of whitespace?
I believe we should, yes.

Related discussion:
text: [rust]: https://www.rust-lang.org <del> “The Rust Programming Language” is split into eight sections. This introduction </del> <ins> “The Rust Programming Language” is split into sections. This introduction </ins> is the first. After this: * [Getting started][gs] - Set up your computer for Rust development. <del> * [Learn Rust][lr] - Learn Rust programming through small projects. * [Effective Rust][er] - Higher-level concepts for writing excellent Rust code. </del> <ins> * [Tutorial: Guessing Game][gg] - Learn some Rust with a small project. </ins> * [Syntax and Semantics][ss] - Each bit of Rust, broken down into small chunks. <ins> * [Effective Rust][er] - Higher-level concepts for writing excellent Rust code. </ins> * [Nightly Rust][nr] - Cutting-edge features that aren’t in stable builds yet. * [Glossary][gl] - A reference of terms used in the book. * [Bibliography][bi] - Background on Rust's influences, papers about Rust. [gs]: getting-started.html <del> [lr]: learn-rust.html </del> <ins> [gg]: guessing-game.html </ins> [er]: effective-rust.html [ss]: syntax-and-semantics.html [nr]: nightly-rust.html [gl]: glossary.html [bi]: bibliography.html <del> After reading this introduction, you’ll want to dive into either ‘Learn Rust’ or ‘Syntax and Semantics’, depending on your preference: ‘Learn Rust’ if you want to dive in with a project, or ‘Syntax and Semantics’ if you prefer to start small, and learn a single concept thoroughly before moving onto the next. Copious cross-linking connects these parts together. </del> ### Contributing The source files from which this book is generated can be found on
Code change:
The presence in a Rust source file of unusual but useful kinds of whitespace, such as ASCII 0x0C (form feed), leads to the following error: I have a specific use case for form-feeds in source files. But I think in general it is nice to ignore the same whitespace that every other programming language and file format ignores; it lessens confusion for people coming from other languages and backgrounds. My specific use case is the long-standing, but somewhat uncommon use of the form-feed character (which semantically is a separator between pages of text) as a way to group together especially closely related functions or blocks in a file of source code. Text editors or IDEs such as vim, Emacs or XCode provide convenience features to display these form-feeds in aesthetically pleasing way, move between form-feed-delimited pages, and restrict editing to one form-feed-delimited page at a time. It's just a simple convenience feature, but it would really be nice to support it.
+1, I also use this feature and was disappointed when I found Rust didn't treat it as whitespace.
Looks like a fairly simple change could be made to the lexer so it uses instead of limiting to . The only think I can think of is that the function in has been around since before we had a better function and nobody has changed it since then.
/cc , do we want to accept all kinds of whitespace?
I believe we should, yes.

Related discussion:
text: # Summary * [Getting Started](getting-started.md) <del> * [Learn Rust](learn-rust.md) * [Guessing Game](guessing-game.md) * [Dining Philosophers](dining-philosophers.md) * [Rust Inside Other Languages](rust-inside-other-languages.md) </del> <ins> * [Tutorial: Guessing Game](guessing-game.md) </ins> * [Syntax and Semantics](syntax-and-semantics.md) * [Variable Bindings](variable-bindings.md) * [Functions](functions.md)
Code change:
The presence in a Rust source file of unusual but useful kinds of whitespace, such as ASCII 0x0C (form feed), leads to the following error: I have a specific use case for form-feeds in source files. But I think in general it is nice to ignore the same whitespace that every other programming language and file format ignores; it lessens confusion for people coming from other languages and backgrounds. My specific use case is the long-standing, but somewhat uncommon use of the form-feed character (which semantically is a separator between pages of text) as a way to group together especially closely related functions or blocks in a file of source code. Text editors or IDEs such as vim, Emacs or XCode provide convenience features to display these form-feeds in aesthetically pleasing way, move between form-feed-delimited pages, and restrict editing to one form-feed-delimited page at a time. It's just a simple convenience feature, but it would really be nice to support it.
+1, I also use this feature and was disappointed when I found Rust didn't treat it as whitespace.
Looks like a fairly simple change could be made to the lexer so it uses instead of limiting to . The only think I can think of is that the function in has been around since before we had a better function and nobody has changed it since then.
/cc , do we want to accept all kinds of whitespace?
I believe we should, yes.

Related discussion:
text: % Guessing Game <del> For our first project, we’ll implement a classic beginner programming problem: the guessing game. Here’s how it works: Our program will generate a random integer between one and a hundred. It will then prompt us to enter a guess. Upon entering our guess, it will tell us if we’re too low or too high. Once we guess correctly, it will congratulate us. Sounds good? </del> <ins> Let’s learn some Rust! For our first project, we’ll implement a classic beginner programming problem: the guessing game. Here’s how it works: Our program will generate a random integer between one and a hundred. It will then prompt us to enter a guess. Upon entering our guess, it will tell us if we’re too low or too high. Once we guess correctly, it will congratulate us. Sounds good? Along the way, we’ll learn a little bit about Rust. The next section, ‘Syntax and Semantics’, will dive deeper into each part. </ins> # Set up
Code change:
On currently nightly, I get: () Yet the description for this error was merged weeks ago:
cc , in the future when adding new diagnostics mods be sure to add a call

Related discussion:
text: ``` ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType` ``` <ins> Note that this does not move `v` (unlike `transmute`), and may need a call to `mem::forget(v)` in case you want to avoid destructors being called. </ins> "##, E0152: r##"
Code change:
Sorting Ipv4Addrs results in unexpected ordering. Ordering is based on the internal representation of the Ipv4Addr without regard to "network order". I tried this code on little-endian architecture: I expected to see this happen: Instead, this happened: Rust playground demonstration:
Ipv6Addr has a similar issue: outputs:

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] impl Ord for Ipv4Addr { fn cmp(&self, other: &Ipv4Addr) -> Ordering { <del> self.inner.s_addr.cmp(&other.inner.s_addr) </del> <ins> self.octets().cmp(&other.octets()) </ins> } }
Code change:
Sorting Ipv4Addrs results in unexpected ordering. Ordering is based on the internal representation of the Ipv4Addr without regard to "network order". I tried this code on little-endian architecture: I expected to see this happen: Instead, this happened: Rust playground demonstration:
Ipv6Addr has a similar issue: outputs:

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] impl Ord for Ipv6Addr { fn cmp(&self, other: &Ipv6Addr) -> Ordering { <del> self.inner.s6_addr.cmp(&other.inner.s6_addr) </del> <ins> self.segments().cmp(&other.segments()) </ins> } }
Code change:
Sorting Ipv4Addrs results in unexpected ordering. Ordering is based on the internal representation of the Ipv4Addr without regard to "network order". I tried this code on little-endian architecture: I expected to see this happen: Instead, this happened: Rust playground demonstration:
Ipv6Addr has a similar issue: outputs:

Related discussion:
text: let a = Ipv4Addr::new(127, 0, 0, 1); assert_eq!(Ipv4Addr::from(2130706433), a); } <ins> #[test] fn ord() { assert!(Ipv4Addr::new(100, 64, 3, 3) < Ipv4Addr::new(192, 0, 2, 2)); assert!("2001:db8:f00::1002".parse::<Ipv6Addr>().unwrap() < "2001:db8:f00::2001".parse::<Ipv6Addr>().unwrap()); } </ins> }
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> // Regression test for #29988 // compile-flags: -C no-prepopulate-passes // only-x86_64 // ignore-windows #[repr(C)] struct S { f1: i32, f2: i32, f3: i32, } extern { fn foo(s: S); } fn main() { let s = S { f1: 1, f2: 2, f3: 3 }; unsafe { // CHECK: load { i64, i32 }, { i64, i32 }* {{.*}}, align 4 // CHECK: call void @foo({ i64, i32 } {{.*}}) foo(s); } } </ins>
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> enum Bug<S> { Var = { let x: S = 0; //~ ERROR: mismatched types 0 }, } fn main() {} </ins>
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[E0308]: mismatched types --> $DIR/issue-67945-1.rs:3:20 | LL | enum Bug<S> { |          - this type parameter LL |     Var = { LL |         let x: S = 0; |                -   ^ expected type parameter `S`, found integer |                | |                expected due to this | = note: expected type parameter `S` found type `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
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> #![feature(type_ascription)] enum Bug<S> { Var = 0: S, //~^ ERROR: mismatched types //~| ERROR: mismatched types } fn main() {} </ins>
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[E0308]: mismatched types --> $DIR/issue-67945-2.rs:4:11 | LL | enum Bug<S> { |          - this type parameter LL |     Var = 0: S, |           ^ expected type parameter `S`, found integer | = note: expected type parameter `S` found type `{integer}` error[E0308]: mismatched types --> $DIR/issue-67945-2.rs:4:11 | LL | enum Bug<S> { |          - this type parameter LL |     Var = 0: S, |           ^^^^ expected `isize`, found type parameter `S` | = note:        expected type `isize` found type parameter `S` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
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> trait Foo {} impl<'a, T> Foo for &'a T {} struct Ctx<'a>(&'a ()) where &'a (): Foo, //~ ERROR: type annotations needed &'static (): Foo; fn main() {} </ins>