jiebi/CodeConvo huggingface dataset:
Code change:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?

Related discussion:
text: note = "if you want to iterate between `start` until a value `end`, use the exclusive range  syntax `start..end` or the inclusive range syntax `start..=end`" ), <ins> on( _Self = "{float}", note = "if you want to iterate between `start` until a value `end`, use the exclusive range  syntax `start..end` or the inclusive range syntax `start..=end`" ), </ins> label = "`{Self}` is not an iterator", message = "`{Self}` is not an iterator" )]
Code change:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?

Related discussion:
text: <ins> // #106728 fn main() { for i in 0.2 { //~^ ERROR `{float}` is not an iterator //~| `{float}` is not an iterator //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` //~| NOTE required for `{float}` to implement `IntoIterator` println!(); } } </ins>
Code change:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?

Related discussion:
text: <ins> error[E0277]: `{float}` is not an iterator --> $DIR/float_iterator_hint.rs:4:14 | LL |     for i in 0.2 { |              ^^^ `{float}` is not an iterator | = help: the trait `Iterator` is not implemented for `{float}` = note: if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` = note: required for `{float}` to implement `IntoIterator` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?

Related discussion:
text: |              ^^^^ `{float}` is not an iterator | = help: the trait `Iterator` is not implemented for `{float}` <ins> = note: if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` </ins> = note: required for `{float}` to implement `IntoIterator` error: aborting due to 12 previous errors
Code change:
Today I synchronized my local version of the rust repo, made a few changes and formatted. This prints: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a known issue, it means that you have a remote to the rust-lang repo that is outdated. The 35k lines likely means that it is at least behind the test move. Does running (replace with the remote name if different) fixes it ?
Maybe we should remove these logs?
There is the same problem if you created lots of file in the formatted directories, but did not track them in git: It will print the name of all of these.
I think we should avoid printing the names of the files if there are more than 10 (or whatever number). That would avoid all similar issues.
claim
Hi! May I know if you're still working on this issue?

Related discussion:
text: if !check && paths.is_empty() { match get_modified_rs_files(build) { Ok(Some(files)) => { <ins> if files.len() <= 10 { for file in &files { println!("formatting modified file {file}"); } } else { println!("formatting {} modified files", files.len()); } </ins> for file in files { <del> println!("formatting modified file {file}"); </del> ignore_fmt.add(&format!("/{file}")).expect(&file); } }
Code change:
The problem is that the configure script assumes that all keys are in a section and there are no top-level keys. This forces people to use instead: We should make it possible to set top-level keys through , both and . We should also update the line in the readme linked above to suggest instead of printf. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: look around I think the fix would be something like .
In the , from where exactly do we get the top-level keys? from the set function?
I'm not sure off the top of my head. How could you find out that information?
Hi are you still working on this?
do you think it's okay to unassign ? This issue is blocking as well.
Since there's no response from the assignee, I think you can take the issue. Are you still keen on working on this issue?
Yup I am interested! claim
Hi and thanks for mentoring! Assuming I run , I think will be 2. So I am not sure if this path would work. It seems like the first blocker is that does not contain or as keys. Should the approach be to expand with those keys? Or should we just allow / as special cases? I am guessing it's closer to the latter, since that might affect the definition of which searches for . Finally, I am a little confused what top-level keys mean - do they exclusively refer to [, ] ? Are there more?
I am able to expand when parsing to include and but I realise I may either have to make changes to or write a new method. Before I do that, I would like to understand how the configure script is commonly used. Could you give me some sample commands, say if I want to modify the field of llvm?
Shall we refactor the 2 top level keys under a section? this makes the parsing logic more consistent and unwieldy lol
you can take a look at for a complete example of what a configuration could look like. I think that would resolve most, if not all of your queries(: Hope this helps!
try running
Got it, thanks I put up a PR. This is kinda my first PR so would appreciate all the tips and advice!

Related discussion:
text: sections[None] = [] section_order = [None] targets = {} <ins> top_level_keys = [] </ins> for line in open(rust_dir + '/config.toml.example').read().split("n"): <ins> if cur_section == None: if line.count('=') == 1: top_level_key = line.split('=')[0] top_level_key = top_level_key.strip(' #') top_level_keys.append(top_level_key) </ins> if line.startswith('['): cur_section = line[1:-1] if cur_section.startswith('target'):
Code change:
(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole

Related discussion:
text: all(target_vendor = "fortanix", target_env = "sgx"), feature(slice_index_methods, coerce_unsized, sgx_platform) )] <ins> #![cfg_attr(windows, feature(round_char_boundary))] </ins> // // Language features: #![feature(alloc_error_handler)]
Code change:
(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole

Related discussion:
text: use crate::ffi::CStr; use crate::mem; <del> use crate::os::raw::{c_char, c_int, c_long, c_longlong, c_uint, c_ulong, c_ushort}; </del> <ins> use crate::os::raw::{c_char, c_long, c_longlong, c_uint, c_ulong, c_ushort}; </ins> use crate::os::windows::io::{BorrowedHandle, HandleOrInvalid, HandleOrNull}; use crate::ptr; use core::ffi::NonZero_c_ulong; use libc::{c_void, size_t, wchar_t}; <ins> pub use crate::os::raw::c_int; </ins> #[path = "c/errors.rs"] // c.rs is included from two places so we need to specify this mod errors; pub use errors::*;
Code change:
(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole

Related discussion:
text: pub const FILE_TYPE_PIPE: u32 = 3; <ins> pub const CP_UTF8: DWORD = 65001; pub const MB_ERR_INVALID_CHARS: DWORD = 0x08; pub const WC_ERR_INVALID_CHARS: DWORD = 0x80; </ins> #[repr(C)] #[derive(Copy)] pub struct WIN32_FIND_DATAW {
Code change:
(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole

Related discussion:
text: lpFilePart: *mut LPWSTR, ) -> DWORD; pub fn GetFileAttributesW(lpFileName: LPCWSTR) -> DWORD; <ins> pub fn MultiByteToWideChar( CodePage: UINT, dwFlags: DWORD, lpMultiByteStr: LPCCH, cbMultiByte: c_int, lpWideCharStr: LPWSTR, cchWideChar: c_int, ) -> c_int; pub fn WideCharToMultiByte( CodePage: UINT, dwFlags: DWORD, lpWideCharStr: LPCWCH, cchWideChar: c_int, lpMultiByteStr: LPSTR, cbMultiByte: c_int, lpDefaultChar: LPCCH, lpUsedDefaultChar: LPBOOL, ) -> c_int; </ins> } #[link(name = "ws2_32")]
Code change:
(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole

Related discussion:
text: } fn write_u16s(handle: c::HANDLE, data: &[u16]) -> io::Result<usize> { <ins> debug_assert!(data.len() < u32::MAX as usize); </ins> let mut written = 0; cvt(unsafe { c::WriteConsoleW(
Code change:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

Related discussion:
text: "{place_name} {partially_str}moved due to this method call{loop_message}", ), ); let infcx = tcx.infer_ctxt().build(); <ins> // Erase and shadow everything that could be passed to the new infcx. </ins> let ty = tcx.erase_regions(moved_place.ty(self.body, tcx).ty); <ins> let method_substs = tcx.erase_regions(method_substs); </ins> if let ty::Adt(def, substs) = ty.kind() && Some(def.did()) == tcx.lang_items().pin_type() && let ty::Ref(_, _, hir::Mutability::Mut) = substs.type_at(0).kind()