jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --When using the syntax in the Display format in formatting macros, the is ignored and treated as a . I tried this code: I expected to see this happen: Getting an error that is out of the bounds for type . Instead, this happened: This function compiles and prints . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I went and looked through the implementation and found where the issue comes from. The check at ignores the integer type, and it blindly calls on the value of the literal.
claim
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Did run a bisection on the reproducible provided (and duplicated ) Regression in nightly-2023-04-22, specifically I think commit or (as pointed out in PR ) found 11 bors merge commits in the specified range commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk commit[2] 2023-04-21: Auto merge of - c410-f3r:dqewdas, r=petrochenkov commit[3] 2023-04-21: Auto merge of - jsoref:spelling-src-etc, r=Mark-Simulacrum commit[4] 2023-04-21: Auto merge of - matthiaskrgr:rollup-, r=matthiaskrgr commit[5] 2023-04-21: Auto merge of - cjgillot:query-feed, r=oli-obk commit[6] 2023-04-21: Auto merge of - michaelvanstraten:master, r=petrochenkov commit[7] 2023-04-21: Auto merge of - petrochenkov:qcstore4, r=cjgillot commit[8] 2023-04-21: Auto merge of - saethlin:mir-pass-cooperation, r=cjgillot commit[9] 2023-04-21: Auto merge of - cjgillot:const-prop-lint-junk, r=oli-obk commit[10] 2023-04-21: Auto merge of - Dylan-DPC:rollup-em3ovcq, r=Dylan-DPC cc
Looks like it's not easy invoke the same integer-literal-range-checking code from the place where formatargs!() is expanded. So the easiest solution is probably to expand to something like when literals are removed, such that the literals are still be checked later.
Actually, looks like there is a much easier fix that mostly just involves removing code. ^^' Will send a PR soon, probably tomorrow.
Fix:

Related discussion:
text: <ins> //@ only-64bit fn main() { format_args!("{}", 0x8f_i8); // issue #115423 //~^ ERROR literal out of range for `i8` format_args!("{}", 0xffff_ffff_u8); // issue #116633 //~^ ERROR literal out of range for `u8` format_args!("{}", 0xffff_ffff_ffff_ffff_ffff_usize); //~^ ERROR literal out of range for `usize` format_args!("{}", 0x8000_0000_0000_0000_isize); //~^ ERROR literal out of range for `isize` format_args!("{}", 0xffff_ffff); // treat unsuffixed literals as i32 //~^ ERROR literal out of range for `i32` } </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected this all to be fine. Instead, the final assertion fails, and the formatting is done like this in the final case: Not sure why 2 decimal places are returned, looks like a bug. This bug also exists in the beta or nightly versions, running in Rust Playground. Discussion: Edit: after looking around the compiler code for the first time I think the problem is somewhere in either or . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
No. The relevant code is actually the one for formatting integers in scientific notation, not floats. I. e. the relevant code is the code first introduced in As I mentioned in the linked URLO thread, I believe perhaps integer formatting in scientific notation should be fully identically behaving to the (seemingly "correct", and also historically older) formatting implementation for floats. This is a potential test we might want passing: but as of now, this kind of test fails in a lot of cases: In this test result, besides the behavior described in this issue, resulting in the wrong number of digits, there’s also the rounding behavior that is different between displaying floats and ints here. I’m not sure whether or not this difference is wanted. If it is_ wanted, it should be properly documented (on that note, I couldn’t easily find any documentation on the rounding used for floats, either), if it isn’t, it would be yet another issue or bug.
I would like to try and fix this bug claim

Related discussion:
text: n /= 10; exponent += 1; } let (added_precision, subtracted_precision) = match f.precision() { Some(fmt_prec) => { // number of decimal digits minus 1
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected this all to be fine. Instead, the final assertion fails, and the formatting is done like this in the final case: Not sure why 2 decimal places are returned, looks like a bug. This bug also exists in the beta or nightly versions, running in Rust Playground. Discussion: Edit: after looking around the compiler code for the first time I think the problem is somewhere in either or . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
No. The relevant code is actually the one for formatting integers in scientific notation, not floats. I. e. the relevant code is the code first introduced in As I mentioned in the linked URLO thread, I believe perhaps integer formatting in scientific notation should be fully identically behaving to the (seemingly "correct", and also historically older) formatting implementation for floats. This is a potential test we might want passing: but as of now, this kind of test fails in a lot of cases: In this test result, besides the behavior described in this issue, resulting in the wrong number of digits, there’s also the rounding behavior that is different between displaying floats and ints here. I’m not sure whether or not this difference is wanted. If it is_ wanted, it should be properly documented (on that note, I couldn’t easily find any documentation on the rounding used for floats, either), if it isn’t, it would be yet another issue or bug.
I would like to try and fix this bug claim

Related discussion:
text: let rem = n % 10; n /= 10; exponent += 1; <del> // round up last digit if rem >= 5 { </del> <ins> // round up last digit, round to even on a tie if rem > 5 || (rem == 5 && (n % 2 != 0 || subtracted_precision > 1 )) { </ins> n += 1; <ins> // if the digit is rounded to the next power // instead adjust the exponent if n.ilog10() > (n - 1).ilog10() { n /= 10; exponent += 1; } </ins> } } (n, exponent, exponent, added_precision)
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: #[cfg(unix)] use crate::os::unix::fs::symlink as symlink_junction; #[cfg(windows)] <del> use crate::os::windows::fs::{symlink_dir, symlink_file}; </del> <ins> use crate::os::windows::fs::{symlink_dir, symlink_file, OpenOptionsExt}; </ins> #[cfg(windows)] use crate::sys::fs::symlink_junction; #[cfg(target_os = "macos")]
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: assert_eq!(socket_path.try_exists().unwrap(), true); assert_eq!(socket_path.metadata().is_ok(), true); } <ins> #[cfg(windows)] #[test] fn test_hidden_file_truncation() { // Make sure that File::create works on an existing hidden file. See #115745. let tmpdir = tmpdir(); let path = tmpdir.join("hidden_file.txt"); // Create a hidden file. const FILE_ATTRIBUTE_HIDDEN: u32 = 2; let mut file = OpenOptions::new() .write(true) .create_new(true) .attributes(FILE_ATTRIBUTE_HIDDEN) .open(&path) .unwrap(); file.write("hidden world!".as_bytes()).unwrap(); file.flush().unwrap(); drop(file); // Create a new file by truncating the existing one. let file = File::create(&path).unwrap(); let metadata = file.metadata().unwrap(); assert_eq!(metadata.len(), 0); } </ins>
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: Windows.Win32.Storage.FileSystem.FILE_ADD_FILE Windows.Win32.Storage.FileSystem.FILE_ADD_SUBDIRECTORY Windows.Win32.Storage.FileSystem.FILE_ALL_ACCESS <ins> Windows.Win32.Storage.FileSystem.FILE_ALLOCATION_INFO </ins> Windows.Win32.Storage.FileSystem.FILE_APPEND_DATA Windows.Win32.Storage.FileSystem.FILE_ATTRIBUTE_ARCHIVE Windows.Win32.Storage.FileSystem.FILE_ATTRIBUTE_COMPRESSED
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: pub type FILE_ACCESS_RIGHTS = u32; pub const FILE_ADD_FILE: FILE_ACCESS_RIGHTS = 2u32; pub const FILE_ADD_SUBDIRECTORY: FILE_ACCESS_RIGHTS = 4u32; <ins> #[repr(C)] pub struct FILE_ALLOCATION_INFO { pub AllocationSize: i64, } impl ::core::marker::Copy for FILE_ALLOCATION_INFO {} impl ::core::clone::Clone for FILE_ALLOCATION_INFO { fn clone(&self) -> Self { *self } } </ins> pub const FILE_ALL_ACCESS: FILE_ACCESS_RIGHTS = 2032127u32; pub const FILE_APPEND_DATA: FILE_ACCESS_RIGHTS = 4u32; pub const FILE_ATTRIBUTE_ARCHIVE: FILE_FLAGS_AND_ATTRIBUTES = 32u32;
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: use crate::os::windows::prelude::*; use crate::borrow::Cow; <del> use crate::ffi::OsString; </del> <ins> use crate::ffi::{c_void, OsString}; </ins> use crate::fmt; use crate::io::{self, BorrowedCursor, Error, IoSlice, IoSliceMut, SeekFrom}; use crate::mem::{self, MaybeUninit};
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: use crate::sys_common::{AsInner, FromInner, IntoInner}; use crate::thread; <del> use core::ffi::c_void; </del> use super::path::maybe_verbatim; use super::to_u16s;
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: (false, false, false) => c::OPEN_EXISTING, (true, false, false) => c::OPEN_ALWAYS, (false, true, false) => c::TRUNCATE_EXISTING, <del> (true, true, false) => c::CREATE_ALWAYS, </del> <ins> // `CREATE_ALWAYS` has weird semantics so we emulate it using // `OPEN_ALWAYS` and a manual truncation step. See #115745. (true, true, false) => c::OPEN_ALWAYS, </ins> (_, _, true) => c::CREATE_NEW, }) }
Code change:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .

Related discussion:
text: impl File { pub fn open(path: &Path, opts: &OpenOptions) -> io::Result<File> { let path = maybe_verbatim(path)?; <ins> let creation = opts.get_creation_mode()?; </ins> let handle = unsafe { c::CreateFileW( path.as_ptr(), opts.get_access_mode()?, opts.share_mode, opts.security_attributes, <del> opts.get_creation_mode()?, </del> <ins> creation, </ins> opts.get_flags_and_attributes(), ptr::null_mut(), ) }; let handle = unsafe { HandleOrInvalid::from_raw_handle(handle) }; <del> if let Ok(handle) = handle.try_into() { </del> <ins> if let Ok(handle) = OwnedHandle::try_from(handle) { // Manual truncation. See #115745. if opts.truncate && creation == c::OPEN_ALWAYS && unsafe { c::GetLastError() } == c::ERROR_ALREADY_EXISTS { unsafe { // Setting the allocation size to zero also sets the // EOF position to zero. let alloc = c::FILE_ALLOCATION_INFO { AllocationSize: 0 }; let result = c::SetFileInformationByHandle( handle.as_raw_handle(), c::FileAllocationInfo, ptr::addr_of!(alloc).cast::<c_void>(), mem::size_of::<c::FILE_ALLOCATION_INFO>() as u32, ); if result == 0 { return Err(io::Error::last_os_error()); } } } </ins> Ok(File { handle: Handle::from_inner(handle) }) } else { Err(Error::last_os_error())
Code change:
The documentation currently says But it also doesn't have an effect if the two lengths are equal, so I think it should say "greater or equal to the vector's current length". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yes, there is a trivial difference between and , but it's an internal implementation issue, I think we should update the doc since they are same from the user's view.
claim

Related discussion:
text: /// Shortens the deque, keeping the first `len` elements and dropping /// the rest. /// <del> /// If `len` is greater than the deque's current length, this has no /// effect. </del> <ins> /// If `len` is greater or equal to the deque's current length, this has /// no effect. </ins> /// /// # Examples ///
Code change:
The documentation currently says But it also doesn't have an effect if the two lengths are equal, so I think it should say "greater or equal to the vector's current length". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yes, there is a trivial difference between and , but it's an internal implementation issue, I think we should update the doc since they are same from the user's view.
claim

Related discussion:
text: /// Shortens the vector, keeping the first `len` elements and dropping /// the rest. /// <del> /// If `len` is greater than the vector's current length, this has no /// effect. </del> <ins> /// If `len` is greater or equal to the vector's current length, this has /// no effect. </ins> /// /// The [`drain`] method can emulate `truncate`, but causes the excess /// elements to be returned instead of dropped.
Code change:
Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .

Related discussion:
text: let reachable_context = ReachableContext::new(tcx, method_map); // Step 1: Seed the worklist with all nodes which were found to be public as <del> //         a result of the privacy pass </del> <ins> //         a result of the privacy pass along with all local lang items. If //         other crates link to us, they're going to expect to be able to //         use the lang items, so we need to be sure to mark them as //         exported. let mut worklist = reachable_context.worklist.borrow_mut(); </ins> for &id in exported_items.iter() { <del> let mut worklist = reachable_context.worklist.borrow_mut(); </del> worklist.get().push(id); } <ins> for (_, item) in tcx.lang_items.items() { match *item { Some(did) if is_local(did) => { worklist.get().push(did.node); } _ => {} } } drop(worklist); </ins> // Step 2: Mark all symbols that the symbols on the worklist touch. reachable_context.propagate();
Code change:
Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .

Related discussion:
text: <ins> // Copyright 2014 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. #[no_std]; #[lang="fail_"] fn fail(_: *i8, _: *i8, _: uint) -> ! { loop {} } #[no_mangle] pub extern "C" fn rust_stack_exhausted() {} </ins>
Code change:
Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .

Related discussion:
text: <ins> // Copyright 2014 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:lang-item-public.rs // ignore-fast // ignore-android #[no_std]; extern crate lang_lib = "lang-item-public"; #[cfg(target_os = "linux")] #[link(name = "c")] extern {} #[cfg(target_os = "android")] #[link(name = "c")] extern {} #[cfg(target_os = "freebsd")] #[link(name = "execinfo")] extern {} #[cfg(target_os = "macos")] #[link(name = "System")] extern {} #[start] fn main(_: int, _: **u8) -> int { 1 % 1 } </ins>