jiebi/CodeConvo huggingface dataset:
Code change:
In it could be useful to explain the and syntax for getting a substring slice. Looking for a way to get a substring reference one is currently with the str API documentation which is quite a lot to digest and if one manages to find the unstable slice_chars(...) it says "Use slicing syntax if you want to use byte indices rather than codepoint indices", but what "slicing syntax" means will probably not be clear to someone who is new to Rust and not yet familiar with the Index trait.

Related discussion:
text: This emphasizes that we have to go through the whole list of `chars`. <ins> ## Slicing You can get a slice of a string with slicing syntax: ```rust let dog = "hachiko"; let hachi = &dog[0..5]; ``` But note that these are _byte_ offsets, not _character_ offsets. So this will fail at runtime: ```rust,should_panic let dog = "忠犬ハチ公"; let hachi = &dog[0..2]; ``` with this error: ```text thread '<main>' panicked at 'index 0 and/or 2 in `忠犬ハチ公` do not lie on character boundary' ``` </ins> ## Concatenation If you have a `String`, you can concatenate a `&str` to the end of it:
Code change:
From , (I assume identical to ) should report nanosecond times as or , not . This reportedly would require fixing in libtest.
I posted a PR for this yesterday. Well I chose to round & use units, but you can opine either way
nice! If you'll just tag that as fixing this then bors will take care of the rest.

Related discussion:
text: } } <ins> // Format a number with thousands separators fn fmt_thousands_sep(mut n: usize, sep: char) -> String { use std::fmt::Write; let mut output = String::new(); let mut first = true; for &pow in &[9, 6, 3, 0] { let base = 10_usize.pow(pow); if pow == 0 || n / base != 0 { if first { output.write_fmt(format_args!("{}", n / base)).unwrap(); } else { output.write_fmt(format_args!("{:03}", n / base)).unwrap(); } if pow != 0 { output.push(sep); } first = false; } n %= base; } output } </ins> pub fn fmt_bench_samples(bs: &BenchSamples) -> String { <ins> use std::fmt::Write; let mut output = String::new(); let median = bs.ns_iter_summ.median as usize; let deviation = (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize; output.write_fmt(format_args!("{:>11} ns/iter (+/- {})", fmt_thousands_sep(median, ','), fmt_thousands_sep(deviation, ','))).unwrap(); </ins> if bs.mb_s != 0 { <del> format!("{:>9} ns/iter (+/- {}) = {} MB/s", bs.ns_iter_summ.median as usize, (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize, bs.mb_s) } else { format!("{:>9} ns/iter (+/- {})", bs.ns_iter_summ.median as usize, (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize) </del> <ins> output.write_fmt(format_args!(" = {} MB/s", bs.mb_s)).unwrap(); </ins> } <ins> output </ins> } // A simple console test runner
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: branches: - 'master' schedule: <del> - cron: '5 15 * * *' # At 15:05 UTC every day. </del> <ins> - cron: '6 6 * * *' # At 6:06 UTC every day. </ins> env: CARGO_UNSTABLE_SPARSE_REGISTRY: 'true'
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: strategy: fail-fast: false matrix: <del> build: [linux64, macos, win32] </del> include: <del> - build: linux64 os: ubuntu-latest </del> <ins> - os: ubuntu-latest </ins> host_target: x86_64-unknown-linux-gnu <del> - build: macos os: macos-latest </del> <ins> - os: macos-latest </ins> host_target: x86_64-apple-darwin <del> - build: win32 os: windows-latest </del> <ins> - os: windows-latest </ins> host_target: i686-pc-windows-msvc steps: - uses: actions/checkout@v3
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: ;; i686-pc-windows-msvc) MIRI_TEST_TARGET=x86_64-unknown-linux-gnu run_tests <ins> MIRI_TEST_TARGET=x86_64-pc-windows-gnu run_tests </ins> ;; *) echo "FATAL: unknown OS"
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: mir, ty::{self, FloatTy, Ty}, }; <del> use rustc_target::abi::Integer; </del> <ins> use rustc_target::abi::{Integer, Size}; </ins> use crate::*; use atomic::EvalContextExt as _;
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: this.write_bytes_ptr(ptr, iter::repeat(val_byte).take(byte_count.bytes_usize()))?; } <ins> "ptr_mask" => { let [ptr, mask] = check_arg_count(args)?; let ptr = this.read_pointer(ptr)?; let mask = this.read_scalar(mask)?.to_machine_usize(this)?; let masked_addr = Size::from_bytes(ptr.addr().bytes() & mask); this.write_pointer(Pointer::new(ptr.provenance, masked_addr), dest)?; } </ins> // Floating-point operations "fabsf32" => { let [f] = check_arg_count(args)?;
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: let [name] = this.check_shim(abi, Abi::C { unwind: false }, link_name, args)?; let thread = this.pthread_self()?; let max_len = this.eval_libc("MAXTHREADNAMESIZE")?.to_machine_usize(this)?; <del> this.pthread_setname_np( </del> <ins> let res = this.pthread_setname_np( </ins> thread, this.read_scalar(name)?, max_len.try_into().unwrap(), )?; <ins> // Contrary to the manpage, `pthread_setname_np` on macOS still // returns an integer indicating success. this.write_scalar(res, dest)?; </ins> } "pthread_getname_np" => { let [thread, name, len] =
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: //@ignore-target-windows: No libc on Windows #![feature(cstr_from_bytes_until_nul)] <del> use std::ffi::CStr; </del> <ins> use std::ffi::{CStr, CString}; </ins> use std::thread; fn main() {
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: .chain(std::iter::repeat(" yada").take(100)) .collect::<String>(); <ins> fn set_thread_name(name: &CStr) -> i32 { #[cfg(target_os = "linux")] return unsafe { libc::pthread_setname_np(libc::pthread_self(), name.as_ptr().cast()) }; #[cfg(target_os = "macos")] return unsafe { libc::pthread_setname_np(name.as_ptr().cast()) }; } </ins> let result = thread::Builder::new().name(long_name.clone()).spawn(move || { // Rust remembers the full thread name itself. assert_eq!(thread::current().name(), Some(long_name.as_str()));
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: // But the system is limited -- make sure we successfully set a truncation. let mut buf = vec![0u8; long_name.len() + 1]; unsafe { <del> libc::pthread_getname_np(libc::pthread_self(), buf.as_mut_ptr().cast(), buf.len()); } </del> <ins> libc::pthread_getname_np(libc::pthread_self(), buf.as_mut_ptr().cast(), buf.len()) }; </ins> let cstr = CStr::from_bytes_until_nul(&buf).unwrap(); assert!(cstr.to_bytes().len() >= 15); // POSIX seems to promise at least 15 chars assert!(long_name.as_bytes().starts_with(cstr.to_bytes())); <ins> // Also test directly calling pthread_setname to check its return value. assert_eq!(set_thread_name(&cstr), 0); // But with a too long name it should fail. assert_ne!(set_thread_name(&CString::new(long_name).unwrap()), 0); </ins> }); result.unwrap().join().unwrap(); }
Code change:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

Related discussion:
text: <ins> #![feature(ptr_mask)] #![feature(strict_provenance)] fn main() { let v: u32 = 0xABCDABCD; let ptr: *const u32 = &v; // u32 is 4 aligned, // so the lower `log2(4) = 2` bits of the address are always 0 assert_eq!(ptr.addr() & 0b11, 0); let tagged_ptr = ptr.map_addr(|a| a | 0b11); let tag = tagged_ptr.addr() & 0b11; let masked_ptr = tagged_ptr.mask(!0b11); assert_eq!(tag, 0b11); assert_eq!(unsafe { *masked_ptr }, 0xABCDABCD); } </ins>
Code change:
Atomics are a language feature that the compiler (LLVM) has to have a deep understanding of in its optimization passes. Send and Sync are also opt-in-built-in-traits, which makes them a pseudo-language construct.
Does this mean Atomics should be mentioned in the Language Reference? What about Send and Sync? Currently, only Sync is mentioned, and that only in passing.

Related discussion:
text: concurrent code at compile time. Before we talk about the concurrency features that come with Rust, it's important <del> to understand something: Rust is low-level enough that all of this is provided by the standard library, not by the language. This means that if you don't like some aspect of the way Rust handles concurrency, you can implement an alternative way of doing things. [mio](https://github.com/carllerche/mio) is a real-world example of this principle in action. </del> <ins> to understand something: Rust is low-level enough that the vast majority of this is provided by the standard library, not by the language. This means that if you don't like some aspect of the way Rust handles concurrency, you can implement an alternative way of doing things. [mio](https://github.com/carllerche/mio) is a real-world example of this principle in action. </ins> ## Background: `Send` and `Sync`
Code change:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.

Related discussion:
text: repr: Repr, } <del> #[derive(Debug)] </del> enum Repr { Os(i32), Custom(Box<Custom>),
Code change:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.

Related discussion:
text: } } <ins> impl fmt::Debug for Repr { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { match self { &Repr::Os(ref code) => fmt.debug_struct("Os").field("code", code) .field("message", &sys::os::error_string(*code)).finish(), &Repr::Custom(ref c) => fmt.debug_tuple("Custom").field(c).finish(), } } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl fmt::Display for Error { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
Code change:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.

Related discussion:
text: use error; use error::Error as error_Error; use fmt; <ins> use sys::os::error_string; #[test] fn test_debug_error() { let code = 6; let msg = error_string(code); let err = Error { repr: super::Repr::Os(code) }; let expected = format!("Error {{ repr: Os {{ code: {:?}, message: {:?} }} }}", code, msg); assert_eq!(format!("{:?}", err), expected); } </ins> #[test] fn test_downcasting() {
Code change:
!.html states that the macro will return a , where in reality it returns . Example: This same problem exists for as well: Documentation at: !.html.

Related discussion:
text: /// A macro which expands to the line number on which it was invoked. /// <del> /// The expanded expression has type `usize`, and the returned line is not </del> <ins> /// The expanded expression has type `u32`, and the returned line is not </ins> /// the invocation of the `line!()` macro itself, but rather the first macro /// invocation leading up to the invocation of the `line!()` macro. ///
Code change:
!.html states that the macro will return a , where in reality it returns . Example: This same problem exists for as well: Documentation at: !.html.

Related discussion:
text: /// A macro which expands to the column number on which it was invoked. /// <del> /// The expanded expression has type `usize`, and the returned column is not </del> <ins> /// The expanded expression has type `u32`, and the returned column is not </ins> /// the invocation of the `column!()` macro itself, but rather the first macro /// invocation leading up to the invocation of the `column!()` macro. ///
Code change:
but The order of the fields is important, and this is something that should be clearly documented, as changing the order of the fields of a struct can change program logic.
generates a lexicographic ordering.

Related discussion:
text: /// /// - total and antisymmetric: exactly one of `a < b`, `a == b` or `a > b` is true; and /// - transitive, `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`. <ins> /// /// When this trait is `derive`d, it produces a lexicographic ordering. </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Ord: Eq + PartialOrd<Self> { /// This method returns an `Ordering` between `self` and `other`.
Code change:
This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

Related discussion:
text: encode_item_sort(rbml_w, 't'); encode_family(rbml_w, 'y'); <ins> if let Some(ty) = associated_type.ty { encode_type(ecx, rbml_w, ty); } </ins> is_nonstatic_method = false; } }
Code change:
This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

Related discussion:
text: // ought to be reported by the type checker method // `check_impl_items_against_trait`, so here we // just return TyError. <ins> debug!("confirm_impl_candidate: no associated type {:?} for {:?}", assoc_ty.name, trait_ref); </ins> return (selcx.tcx().types.err, vec!()); } }
Code change:
This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub trait Foo { type Input = usize; fn bar(&self, _: Self::Input) {} } impl Foo for () {} </ins>
Code change:
This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:xcrate_associated_type_defaults.rs extern crate xcrate_associated_type_defaults; use xcrate_associated_type_defaults::Foo; fn main() { ().bar(5); } </ins>
Code change:
Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.

Related discussion:
text: match base_cmt.cat { mc::cat_upvar(mc::Upvar { id: ty::UpvarId { var_id: vid, .. }, .. }) | mc::cat_local(vid) => { <del> self.reassigned |= self.node == vid && Some(field) == self.field </del> <ins> self.reassigned |= self.node == vid && (self.field.is_none() || Some(field) == self.field) </ins> }, _ => {} }
Code change:
Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut c = (1, "".to_owned()); match c { c2 => { c.0 = 2; assert_eq!(c2.0, 1); } } } </ins>
Code change:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.

Related discussion:
text: // FOREIGN STATIC ITEM return Ok(Some(self.parse_item_foreign_static(visibility, lo, attrs)?)); } <del> if self.check_keyword(keywords::Fn) || self.check_keyword(keywords::Unsafe) { </del> <ins> if self.check_keyword(keywords::Fn) { </ins> // FOREIGN FUNCTION ITEM return Ok(Some(self.parse_item_foreign_fn(visibility, lo, attrs)?)); }
Code change:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.

Related discussion:
text: // compile-flags: -Z parse-only extern { <del> f(); //~ ERROR expected one of `fn`, `pub`, `static`, `unsafe`, or `}`, found `f` </del> <ins> f(); //~ ERROR expected one of `fn`, `pub`, `static`, or `}`, found `f` </ins> } fn main() {
Code change:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.

Related discussion:
text: extern { const i: isize; <del> //~^ ERROR expected one of `fn`, `pub`, `static`, `unsafe`, or `}`, found `const` </del> <ins> //~^ ERROR expected one of `fn`, `pub`, `static`, or `}`, found `const` </ins> }