Question:
<!-- 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:

<ins> error: literal out of range for `i8` --> $DIR/no-inline-literals-out-of-range.rs:4:24 | LL |     format_args!("{}", 0x8f_i8); // issue #115423 |                        ^^^^^^^ | = note: the literal `0x8f_i8` (decimal `143`) does not fit into the type `i8` and will become `-113i8` = note: `#[deny(overflowing_literals)]` on by default help: consider using the type `u8` instead | LL |     format_args!("{}", 0x8f_u8); // issue #115423 |                        ~~~~~~~ help: to use as a negative number (decimal `-113`), consider using the type `u8` for the literal and cast it to `i8` | LL |     format_args!("{}", 0x8f_u8 as i8); // issue #115423 |                        ~~~~~~~~~~~~~ error: literal out of range for `u8` --> $DIR/no-inline-literals-out-of-range.rs:6:24 | LL |     format_args!("{}", 0xffff_ffff_u8); // issue #116633 |                        ^^^^^^^^^^^^^^ help: consider using the type `u32` instead: `0xffff_ffff_u32` | = note: the literal `0xffff_ffff_u8` (decimal `4294967295`) does not fit into the type `u8` and will become `255u8` error: literal out of range for `usize` --> $DIR/no-inline-literals-out-of-range.rs:8:24 | LL |     format_args!("{}", 0xffff_ffff_ffff_ffff_ffff_usize); |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the literal `0xffff_ffff_ffff_ffff_ffff_usize` (decimal `1208925819614629174706175`) does not fit into the type `usize` and will become `18446744073709551615usize` error: literal out of range for `isize` --> $DIR/no-inline-literals-out-of-range.rs:10:24 | LL |     format_args!("{}", 0x8000_0000_0000_0000_isize); |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the literal `0x8000_0000_0000_0000_isize` (decimal `9223372036854775808`) does not fit into the type `isize` and will become `-9223372036854775808isize` error: literal out of range for `i32` --> $DIR/no-inline-literals-out-of-range.rs:12:24 | LL |     format_args!("{}", 0xffff_ffff); // treat unsuffixed literals as i32 |                        ^^^^^^^^^^^ | = note: the literal `0xffff_ffff` (decimal `4294967295`) does not fit into the type `i32` and will become `-1i32` = help: consider using the type `u32` instead help: to use as a negative number (decimal `-1`), consider using the type `u32` for the literal and cast it to `i32` | LL |     format_args!("{}", 0xffff_ffffu32 as i32); // treat unsuffixed literals as i32 |                        ~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 5 previous errors </ins>


Question:
<!-- 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

n /= 10; exponent += 1; } let (added_precision, subtracted_precision) = match f.precision() { Some(fmt_prec) => { // number of decimal digits minus 1


Question:
<!-- 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

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)


Question:
<!-- 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

let big_int: u32 = 314_159_265; assert_eq!(format!("{big_int:.1e}"), format!("{:.1e}", f64::from(big_int))); <del> //test adding precision </del> <ins> // test adding precision </ins> assert_eq!(format!("{:.10e}", i8::MIN), "-1.2800000000e2"); assert_eq!(format!("{:.10e}", i16::MIN), "-3.2768000000e4"); assert_eq!(format!("{:.10e}", i32::MIN), "-2.1474836480e9"); assert_eq!(format!("{:.20e}", i64::MIN), "-9.22337203685477580800e18"); assert_eq!(format!("{:.40e}", i128::MIN), "-1.7014118346046923173168730371588410572800e38"); <del> //test rounding </del> <ins> // test rounding </ins> assert_eq!(format!("{:.1e}", i8::MIN), "-1.3e2"); assert_eq!(format!("{:.1e}", i16::MIN), "-3.3e4"); assert_eq!(format!("{:.1e}", i32::MIN), "-2.1e9"); assert_eq!(format!("{:.1e}", i64::MIN), "-9.2e18"); assert_eq!(format!("{:.1e}", i128::MIN), "-1.7e38"); <del> //test huge precision </del> <ins> // test huge precision </ins> assert_eq!(format!("{:.1000e}", 1), format!("1.{}e0", "0".repeat(1000))); //test zero precision assert_eq!(format!("{:.0e}", 1), format!("1e0",)); assert_eq!(format!("{:.0e}", 35), format!("4e1",)); <del> //test padding with precision (and sign) </del> <ins> // test padding with precision (and sign) </ins> assert_eq!(format!("{:+10.3e}", 1), "  +1.000e0"); <ins> // test precision remains correct when rounding to next power for i in i16::MIN..=i16::MAX { for p in 0..=5 { assert_eq!( format!("{i:.p$e}"), format!("{:.p$e}", f32::from(i)), "integer {i} at precision {p}" ); } } </ins> } #[test]


Question:
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 .

#[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")]


Question:
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 .

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>


Question:
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 .

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


Question:
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 .

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;


Question:
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 .

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};


Question:
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 .

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;


Question:
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 .

(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, }) }


Question:
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 .

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())


Question:
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

/// 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 ///


Question:
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

/// 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.


Question:
available_parallelism() return 0 I tried this code: : ! <details<summarycat /proc/cpuinfo</summary<p</p</details
Looking at the , it appears that if returned 0 it would indeed be a problem, but why would that be? Could you try to run this small program, and return us the output of it? If it prints out for the could you also attach . label +T-libs +I-prioritize +O-linux -needs-triage
!
Can you post the output of running your test program with ? I'm just hoping you have some way to get strace onto this router :pray:
Right, that's what I thought. Let's try to pin point where the bug is by trying the same thing in C. Could you try to run this small program, and return us the output of it?
I think for any reason, when the value of 'CPUCOUNT' is 0, 'availableparallelism' should return Err
Sorry, I don't know how to compile C program onto the router
Well yes, but we shouldn't get 0 for starter. Hum, that's a bummer. Then I don't know how to debug this further.
Can you provide the compiled binary for me to run? The system environment has been given
I'm sorry, I don't know your environment, and I haven't used any MIPS. However if you able to compile with  as a dependency, we might be able to continue debugging. Could you try to run this small program, and return us the output of it? <details if needed</summary</details
Related: Unlike numcpus, which returns usize, std returns NoneZeroUsize, so this is a soundness issue. label +I-unsound
should probably just handle this by returning if fails rather than using . It's a weird issue (obviously there is at least 1 CPU if code is running) but who knows.
Maybe it's worth saying this explicitly: As far as I can tell by reading the man pages, this is a bug in glibc or Linux. The man pages for and don't look like there is any wiggle room for a platform to behave like this. Has anyone tried reporting this upstream? This issue is not the first time this problem has been encountered, but it looks to me like everyone else has papered over it.
If we're down for cursed things, this program will print the raw bytes in the cpuset which would at least let us know if the kernel is putting anything in there:
libc::CPUCOUNT is implemented in pure rust with straightforward code: I'm not sure I think there's a way for that code to fail to miss any bits.
you haven't mentioned which target-triple you're compiling for. Some are tier 2 and some are tier 3. Some use glibc, some musl. This could be relevant if it's a bug in libc.
This kernel version and is below the for the tier 2 mips-gnu targets.
The docs for already mention that it returns an estimate, rather than an accurate count. I take this mean a lower bound, so a fallback of would be consistent with my expectations. But I'll admit the docs do also seem to contradict themselves a few paragraphs later:
Regardless of whether this kernel is EOL (we support plenty of EOL kernels) and whether the wobbliness of applies here (I'm sure it doesn't, and it would be terrible for us to retcon this as permitted behavior), I think the problem here is that your kernel is buggy. A quick Google search for "mips schedgetaffinity" turns up this patch: Just going off vibes, this looks like it fixes the bug we are talking about. As was pointed out correctly above, the kernel you're using is not supported by this target, and upgrading to a supported kernel would bring in the patch above. Can you confirm that upgrading to a supported kernel (at least 4.4)? If an upgrade to at least Linux 4.4 fixes this issue, I do not think we should try to fall back to returning 1 if says . Might be nice to panic instead of executing UB though.
Yeah, panic makes sense. We should notify users that the system is bugged and unsupported. I'll make a PR.

if libc::sched_getaffinity(0, mem::size_of::<libc::cpu_set_t>(), &mut set) == 0 { let count = libc::CPU_COUNT(&set) as usize; let count = count.min(quota); <del> // SAFETY: affinity mask can't be empty and the quota gets clamped to a minimum of 1 return Ok(NonZeroUsize::new_unchecked(count)); </del> <ins> // reported to occur on MIPS kernels older than our minimum supported kernel version for those targets let count = NonZeroUsize::new(count) .expect("CPU count must be > 0. This may be a bug in sched_getaffinity(); try upgrading the kernel."); return Ok(count); </ins> } } }


Question:
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 .

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();


Question:
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 .

<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>


Question:
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 .

<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>


Question:
The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.

///     surprising results upon inspecting the bit patterns, ///     as the same calculations might produce NaNs with different bit patterns. /// <del> /// When the number resulting from a primitive operation (addition, /// subtraction, multiplication, or division) on this type is not exactly /// representable as `f32`, it is rounded according to the roundTiesToEven /// direction defined in IEEE 754-2008. That means: </del> <ins> /// When a primitive operation (addition, subtraction, multiplication, or /// division) is performed on this type, the result is rounded according to the /// roundTiesToEven direction defined in IEEE 754-2008. That means: </ins> /// /// - The result is the representable value closest to the true value, if there ///   is a unique closest representable value.


Question:
The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.

/// - If the true value's magnitude is ≥ `f32::MAX` + 2<sup>(`f32::MAX_EXP` − ///   `f32::MANTISSA_DIGITS` − 1)</sup>, the result is ∞ or −∞ (preserving the ///   true value's sign). <ins> /// - If the result of a sum exactly equals zero, the outcome is +0.0 unless ///   both arguments were negative, then it is -0.0. Subtraction `a - b` is ///   regarded as a sum `a + (-b)`. </ins> /// /// For more information on floating point numbers, see [Wikipedia][wikipedia]. ///


Question:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

use cell::RefCell; use intrinsics; use sync::StaticRwLock; <ins> use sync::atomic::{AtomicBool, Ordering}; </ins> use sys::stdio::Stderr; use sys_common::backtrace; use sys_common::thread_info;


Question:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

static HANDLER_LOCK: StaticRwLock = StaticRwLock::new(); static mut HANDLER: Handler = Handler::Default; <ins> static FIRST_PANIC: AtomicBool = AtomicBool::new(true); </ins> /// Registers a custom panic handler, replacing any that was previously /// registered.


Question:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

let write = |err: &mut ::io::Write| { let _ = writeln!(err, "thread '{}' panicked at '{}', {}:{}", name, msg, file, line); if log_backtrace { let _ = backtrace::write(err); <ins> } else if FIRST_PANIC.compare_and_swap(true, false, Ordering::SeqCst) { let _ = writeln!(err, "note: Run with `RUST_BACKTRACE=1` for a backtrace."); </ins> } };


Question:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

<ins> // Copyright 2016 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 args: Vec<String> = std::env::args().collect(); if args.len() > 1 && args[1] == "run_test" { let _ = std::thread::spawn(|| { panic!(); }).join(); panic!(); } else { let test = std::process::Command::new(&args[0]).arg("run_test").output().unwrap(); assert!(!test.status.success()); let err = String::from_utf8_lossy(&test.stderr); let mut it = err.lines(); assert_eq!(it.next().map(|l| l.starts_with("thread '<unnamed>' panicked at")), Some(true)); assert_eq!(it.next(), Some("note: Run with `RUST_BACKTRACE=1` for a backtrace.")); assert_eq!(it.next().map(|l| l.starts_with("thread '<main>' panicked at")), Some(true)); assert_eq!(it.next(), None); } } </ins>


Question:
https://crater-
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-10 regressed nightly: nightly-2023-09-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsthis bisection may look pretty nonsensical, but I did manually confirm that nightly-2023-09-14 worked and nightly-2023-09-16 didn't. I am surprised that this ever parsed, and given that there's only a single random repo that regressed, and the regressing code is a mistake, I don't think this is a problematic regression. anyways.
Agreed that we don't necessarily need a fix, but we should try to make sure that this is indeed limited to this one case (i.e., it's not some broader incompatibility that may have gone uncaught in Crater)
The change here is that AST validation is now checking that the attribute is valid. Some other cases: Marking as needs-test, with the new behavior being correct

<ins> // test for #117058 - check that attributes are validated on various kinds of statements. struct A; fn func() {} fn main() { #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` if true { } else { } #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` (1); #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` match 1 { _ => {} } #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` while false {} #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` {} #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` A {}; #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` func(); #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` A; #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` loop {} } </ins>


Question:
https://crater-
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-10 regressed nightly: nightly-2023-09-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsthis bisection may look pretty nonsensical, but I did manually confirm that nightly-2023-09-14 worked and nightly-2023-09-16 didn't. I am surprised that this ever parsed, and given that there's only a single random repo that regressed, and the regressing code is a mistake, I don't think this is a problematic regression. anyways.
Agreed that we don't necessarily need a fix, but we should try to make sure that this is indeed limited to this one case (i.e., it's not some broader incompatibility that may have gone uncaught in Crater)
The change here is that AST validation is now checking that the attribute is valid. Some other cases: Marking as needs-test, with the new behavior being correct

<ins> error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:8:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:13:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:16:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:21:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:24:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:27:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:30:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:33:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:36:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: aborting due to 9 previous errors </ins>


Question:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.

expected: Ty<'tcx>, found: Ty<'tcx>, ) -> bool { <del> let ty::Adt(adt, args) = found.kind() else { return false }; </del> <ins> let ty::Adt(adt, args) = found.kind() else { return false; }; </ins> let ret_ty_matches = |diagnostic_item| { <del> if let Some(ret_ty) = self .ret_coercion .as_ref() .map(|c| self.resolve_vars_if_possible(c.borrow().expected_ty())) && let ty::Adt(kind, _) = ret_ty.kind() && self.tcx.get_diagnostic_item(diagnostic_item) == Some(kind.did()) { true } else { false } </del> <ins> let Some(sig) = self.body_fn_sig() else { return false; }; let ty::Adt(kind, _) = sig.output().kind() else { return false; }; self.tcx.is_diagnostic_item(diagnostic_item, kind.did()) </ins> }; // don't suggest anything like `Ok(ok_val).unwrap()` , `Some(some_val).unwrap()`,


Question:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.

<ins> // edition: 2021 async fn dont_suggest() -> i32 { if false { return Ok(6); //~^ ERROR mismatched types } 5 } async fn do_suggest() -> i32 { if false { let s = Ok(6); return s; //~^ ERROR mismatched types } 5 } fn main() {} </ins>


Question:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.

<ins> error[E0308]: mismatched types --> $DIR/async-unwrap-suggestion.rs:5:16 | LL |         return Ok(6); |                ^^^^^ expected `i32`, found `Result<{integer}, _>` | = note: expected type `i32` found enum `Result<{integer}, _>` error[E0308]: mismatched types --> $DIR/async-unwrap-suggestion.rs:15:16 | LL |         return s; |                ^ expected `i32`, found `Result<{integer}, _>` | = note: expected type `i32` found enum `Result<{integer}, _>` help: consider using `Result::expect` to unwrap the `Result<{integer}, _>` value, panicking if the value is a `Result::Err` | LL |         return s.expect("REASON"); |                 +++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

("macro_registrar", Active), ("log_syntax", Active), ("trace_macros", Active), <ins> ("simd", Active), </ins> // These are used to test this portion of the compiler, they don't actually // mean anything


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

} } <ins> ast::ItemStruct(..) => { if attr::contains_name(i.attrs, "simd") { self.gate_feature("simd", i.span, "SIMD types are experimental and possibly buggy"); } } </ins> _ => {} }


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")]; <del> #[feature(macro_rules, globs, asm, managed_boxes, thread_local, link_args)]; </del> <ins> #[feature(macro_rules, globs, asm, managed_boxes, thread_local, link_args, simd)]; </ins> // Don't link to std. We are std. #[no_std]; #[deny(non_camel_case_types)]; #[deny(missing_doc)]; <ins> #[allow(unknown_features)]; </ins> // When testing libstd, bring in libuv as the I/O backend so tests can print // things and all of the std::io tests have an I/O interface to run on top


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

#[allow(non_camel_case_types)]; <ins> #[experimental] </ins> #[simd] pub struct i8x16(i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8); <ins> #[experimental] </ins> #[simd] pub struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16); <ins> #[experimental] </ins> #[simd] pub struct i32x4(i32, i32, i32, i32); <ins> #[experimental] </ins> #[simd] pub struct i64x2(i64, i64); <ins> #[experimental] </ins> #[simd] pub struct u8x16(u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8); <ins> #[experimental] </ins> #[simd] pub struct u16x8(u16, u16, u16, u16, u16, u16, u16, u16); <ins> #[experimental] </ins> #[simd] pub struct u32x4(u32, u32, u32, u32); <ins> #[experimental] </ins> #[simd] pub struct u64x2(u64, u64); <ins> #[experimental] </ins> #[simd] pub struct f32x4(f32, f32, f32, f32); <ins> #[experimental] </ins> #[simd] pub struct f64x2(f64, f64);


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

<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. #[simd] pub struct i64x2(i64, i64); //~ ERROR: SIMD types are experimental fn main() {} </ins>  No newline at end of file


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

<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. // xfail-test FIXME #11741 tuple structs ignore stability attributes #[deny(experimental)]; use std::unstable::simd; fn main() { let _ = simd::i64x2(0, 0); //~ ERROR: experimental } </ins>


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

<ins> #[feature(simd)]; </ins> #[simd] struct vec4<T>(T, T, T, T); //~ ERROR SIMD vector cannot be generic


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #[allow(experimental)]; </ins> use std::unstable::simd::{i32x4, f32x4}; fn test_int(e: i32) -> i32 {


Question:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

<ins> // xfail-fast feature doesn't work #[feature(simd)]; </ins> #[simd] struct RGBA { r: f32,


Question:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

// types are fine though. ty::ConstKind::Value(_) => c.ty().is_primitive(), ty::ConstKind::Unevaluated(..) | ty::ConstKind::Expr(..) => false, <ins> // This can happen if evaluation of a constant failed. The result does not matter // much since compilation is doomed. ty::ConstKind::Error(..) => false, </ins> // Should not appear in runtime MIR. ty::ConstKind::Infer(..) | ty::ConstKind::Bound(..) <del> | ty::ConstKind::Placeholder(..) | ty::ConstKind::Error(..) => bug!(), </del> <ins> | ty::ConstKind::Placeholder(..) => bug!(), </ins> }, Const::Unevaluated(..) => false, // If the same slice appears twice in the MIR, we cannot guarantee that we will


Question:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

<ins> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:16:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:5 | LL |     &<A<T> as Foo<T>>::BAR |     ^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>


Question:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

<ins> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:16:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn foo::<()>` --> $DIR/issue-50814-2.rs:32:22 | LL |     println!("{:x}", foo::<()>() as *const usize as usize); |                      ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>


Question:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

// build-fail <ins> // revisions: normal mir-opt // [mir-opt]compile-flags: -Zmir-opt-level=4 </ins> trait C { const BOO: usize;


Question:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

<del> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:14:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:18:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn foo::<()>` --> $DIR/issue-50814-2.rs:30:22 | LL |     println!("{:x}", foo::<()>() as *const usize as usize); |                      ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </del>


Question:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.

// - use std::lazy for `Lazy` // - use std::cell for `OnceCell` // Once they get stabilized and reach beta. <ins> use build_helper::ci::CiEnv; </ins> use clap::ValueEnum; use once_cell::sync::{Lazy, OnceCell};


Question:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.

self.clear_if_dirty(&out_dir, &backend); } <del> if cmd == "doc" || cmd == "rustdoc" { </del> <ins> if cmd == "doc" || cmd == "rustdoc" // FIXME: We shouldn't need to check this. // ref https://github.com/rust-lang/rust/issues/117430#issuecomment-1788160523 && !CiEnv::is_ci() { </ins> let my_out = match mode { // This is the intended out directory for compiler documentation. Mode::Rustc | Mode::ToolRustc => self.compiler_doc_out(target),


Question:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.

} fn run(self, builder: &Builder<'_>) -> Option<GeneratedTarball> { <del> if builder.config.dry_run() { return None; } </del> // This prevents rustc_codegen_cranelift from being built for "dist" // or "install" on the stable/beta channels. It is not yet stable and // should not be included.


Question:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.

return None; } <del> if !builder.config.rust_codegen_backends.contains(&self.backend) { return None; } </del> if self.backend == "cranelift" { if !target_supports_cranelift_backend(self.compiler.host) { builder.info("target not supported by rustc_codegen_cranelift. skipping");


Question:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.

let backends_dst = PathBuf::from("lib").join(&backends_rel); let backend_name = format!("rustc_codegen_{}", backend); <del> let mut found_backend = false; </del> for backend in fs::read_dir(&backends_src).unwrap() { let file_name = backend.unwrap().file_name(); if file_name.to_str().unwrap().contains(&backend_name) { tarball.add_file(backends_src.join(file_name), &backends_dst, 0o644); <del> found_backend = true; </del> } } <del> assert!(found_backend); </del> Some(tarball.generate()) }


Question:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.

--env DIST_TRY_BUILD  --env PR_CI_JOB  --env OBJDIR_ON_HOST="$objdir"  <del> --env CODEGEN_BACKENDS  </del> --init  --rm  rust-ci


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
/ ping :grin:

match err { LayoutError::Unknown(..) | LayoutError::ReferencesError(..) => Self::UnknownLayout, LayoutError::SizeOverflow(..) => Self::SizeOverflow, <ins> LayoutError::Cycle(err) => Self::TypeError(*err), </ins> err => unimplemented!("{:?}", err), } }


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
/ ping :grin:

<ins> //~ ERROR: cycle detected //! Safe transmute did not handle cycle errors that could occur during //! layout computation. This test checks that we do not ICE in such //! situations (see #117491). #![crate_type = "lib"] #![feature(transmutability)] #![allow(dead_code, incomplete_features, non_camel_case_types)] mod assert { use std::mem::{Assume, BikeshedIntrinsicFrom}; pub struct Context; pub fn is_maybe_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src, Context>, { } } fn should_pad_explicitly_packed_field() { #[repr(C)] struct ExplicitlyPadded(ExplicitlyPadded); //~^ ERROR: recursive type assert::is_maybe_transmutable::<ExplicitlyPadded, ()>(); } </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
/ ping :grin:

<ins> error[E0072]: recursive type `ExplicitlyPadded` has infinite size --> $DIR/transmute_infinitely_recursive_type.rs:22:5 | LL |     struct ExplicitlyPadded(ExplicitlyPadded); |     ^^^^^^^^^^^^^^^^^^^^^^^ ---------------- recursive without indirection | help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle | LL |     struct ExplicitlyPadded(Box<ExplicitlyPadded>); |                             ++++                + error[E0391]: cycle detected when computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded` | = note: ...which immediately requires computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded` again = note: cycle used when evaluating trait selection obligation `(): core::mem::transmutability::BikeshedIntrinsicFrom<should_pad_explicitly_packed_field::ExplicitlyPadded, assert::Context, core::mem::transmutability::Assume { alignment: false, lifetimes: false, safety: false, validity: false }>` = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 2 previous errors Some errors have detailed explanations: E0072, E0391. For more information about an error, try `rustc --explain E0072`. </ins>


Question: When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response

span, if span_to_replace.is_some() { constraint.clone() <ins> } else if constraint.starts_with("<") { constraint.to_string() </ins> } else if bound_list_non_empty { format!(" + {constraint}") } else {


Question: When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response

<ins> // run-rustfix pub trait MyTrait { type T; fn bar(self) -> Self::T; } pub fn foo<A: MyTrait<T = B>, B>(a: A) -> B { return a.bar(); //~ ERROR mismatched types } fn main() {} </ins>


Question: When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response

<ins> // run-rustfix pub trait MyTrait { type T; fn bar(self) -> Self::T; } pub fn foo<A: MyTrait, B>(a: A) -> B { return a.bar(); //~ ERROR mismatched types } fn main() {} </ins>


Question: When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response

<ins> error[E0308]: mismatched types --> $DIR/restrict-assoc-type-of-generic-bound.rs:9:12 | LL | pub fn foo<A: MyTrait, B>(a: A) -> B { |                        -           - expected `B` because of return type |                        | |                        expected this type parameter LL |     return a.bar(); |            ^^^^^^^ expected type parameter `B`, found associated type | = note: expected type parameter `B` found associated type `<A as MyTrait>::T` help: consider further restricting this bound | LL | pub fn foo<A: MyTrait<T = B>, B>(a: A) -> B { |                      +++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
Reported by a lz4flex user I created a small repo to demonstrate on a minimal example. BorrowedCursor::ensureinit from this PR seems exhibit exponential cost. The program creates a Vec and reads it in chunks of 32kb. Size is specified as a command line argument (100MB-400MB). (If your default is 1.73) <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-stable -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Maybe try (tutorial: https://rust-) to find which PR caused this?
Really nice bisect tool. From the commit list in that Auto merge it seems to be
cc author
The loop creates a new on each iteration, which is fine if the reader can fill the provided buffer in one go but does unnecessary work on short reads. Should be easy to fix. claim
Any chance of getting this fix in a backport to 1.73?

use super::{BorrowedBuf, BufReader, BufWriter, Read, Result, Write, DEFAULT_BUF_SIZE}; use crate::alloc::Allocator; use crate::cmp; <ins> use crate::cmp::min; </ins> use crate::collections::VecDeque; use crate::io::IoSlice; use crate::mem::MaybeUninit;


Question:
Reported by a lz4flex user I created a small repo to demonstrate on a minimal example. BorrowedCursor::ensureinit from this PR seems exhibit exponential cost. The program creates a Vec and reads it in chunks of 32kb. Size is specified as a command line argument (100MB-400MB). (If your default is 1.73) <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-stable -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Maybe try (tutorial: https://rust-) to find which PR caused this?
Really nice bisect tool. From the commit list in that Auto merge it seems to be
cc author
The loop creates a new on each iteration, which is fine if the reader can fill the provided buffer in one go but does unnecessary work on short reads. Should be easy to fix. claim
Any chance of getting this fix in a backport to 1.73?

fn copy_from<R: Read + ?Sized>(&mut self, reader: &mut R) -> Result<u64> { let mut bytes = 0; <del> // avoid allocating before we have determined that there's anything to read if self.capacity() == 0 { bytes = stack_buffer_copy(&mut reader.take(DEFAULT_BUF_SIZE as u64), self)?; if bytes == 0 { return Ok(0); </del> <ins> // avoid inflating empty/small vecs before we have determined that there's anything to read if self.capacity() < DEFAULT_BUF_SIZE { let stack_read_limit = DEFAULT_BUF_SIZE as u64; bytes = stack_buffer_copy(&mut reader.take(stack_read_limit), self)?; // fewer bytes than requested -> EOF reached if bytes < stack_read_limit { return Ok(bytes); </ins> } } <ins> // don't immediately offer the vec's whole spare capacity, otherwise // we might have to fully initialize it if the reader doesn't have a custom read_buf() impl let mut max_read_size = DEFAULT_BUF_SIZE; </ins> loop { self.reserve(DEFAULT_BUF_SIZE); <del> let mut buf: BorrowedBuf<'_> = self.spare_capacity_mut().into(); match reader.read_buf(buf.unfilled()) { Ok(()) => {} Err(e) if e.is_interrupted() => continue, Err(e) => return Err(e), }; </del> <ins> let mut initialized_spare_capacity = 0; </ins> <del> let read = buf.filled().len(); if read == 0 { break; } </del> <ins> loop { let buf = self.spare_capacity_mut(); let read_size = min(max_read_size, buf.len()); let mut buf = BorrowedBuf::from(&mut buf[..read_size]); // SAFETY: init is either 0 or the init_len from the previous iteration. unsafe { buf.set_init(initialized_spare_capacity); } match reader.read_buf(buf.unfilled()) { Ok(()) => { let bytes_read = buf.len(); </ins> <del> // SAFETY: BorrowedBuf guarantees all of its filled bytes are init // and the number of read bytes can't exceed the spare capacity since // that's what the buffer is borrowing from. unsafe { self.set_len(self.len() + read) }; bytes += read as u64; } </del> <ins> // EOF if bytes_read == 0 { return Ok(bytes); } </ins> <del> Ok(bytes) </del> <ins> // the reader is returning short reads but it doesn't call ensure_init() if buf.init_len() < buf.capacity() { max_read_size = usize::MAX; } // the reader hasn't returned short reads so far if bytes_read == buf.capacity() { max_read_size *= 2; } initialized_spare_capacity = buf.init_len() - bytes_read; bytes += bytes_read as u64; // SAFETY: BorrowedBuf guarantees all of its filled bytes are init // and the number of read bytes can't exceed the spare capacity since // that's what the buffer is borrowing from. unsafe { self.set_len(self.len() + bytes_read) }; // spare capacity full, reserve more if self.len() == self.capacity() { break; } } Err(e) if e.is_interrupted() => continue, Err(e) => return Err(e), } } } </ins> } }


Question:
<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it

// Equate the headers to find their intersection (the general type, with infer vars, // that may apply both impls). <del> let Some(_equate_obligations) = </del> <ins> let Some(equate_obligations) = </ins> equate_impl_headers(infcx, param_env, &impl1_header, &impl2_header) else { return false;


Question:
<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it

plug_infer_with_placeholders(infcx, universe, (impl1_header.impl_args, impl2_header.impl_args)); <ins> // FIXME(with_negative_coherence): the infcx has constraints from equating // the impl headers. We should use these constraints as assumptions, not as // requirements, when proving the negated where clauses below. drop(equate_obligations); drop(infcx.take_registered_region_obligations()); drop(infcx.take_and_reset_region_constraints()); </ins> util::elaborate(tcx, tcx.predicates_of(impl2_def_id).instantiate(tcx, impl2_header.impl_args)) .any(|(clause, _)| try_prove_negated_where_clause(infcx, clause, param_env)) }


Question:
<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it

return false; }; <del> // FIXME(with_negative_coherence): the infcx has region contraints from equating // the impl headers as requirements. Given that the only region constraints we // get are involving inference regions in the root, it shouldn't matter, but // still sus. // // We probably should just throw away the region obligations registered up until // now, or ideally use them as assumptions when proving the region obligations // that we get from proving the negative predicate below. </del> let ref infcx = root_infcx.fork(); let ocx = ObligationCtxt::new(infcx);


Question:
<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it

<ins> error: conflicting implementations of trait `FnMarker` for type `fn(&_)` --> $DIR/negative-coherence-placeholder-region-constraints-on-unification.rs:21:1 | LL | impl<T: ?Sized + Marker> FnMarker for fn(T) {} | ------------------------------------------- first implementation here LL | impl<T: ?Sized> FnMarker for fn(&T) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `fn(&_)` | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105> = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details note: the lint level is defined here --> $DIR/negative-coherence-placeholder-region-constraints-on-unification.rs:4:11 | LL | #![forbid(coherence_leak_check)] |           ^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it

<ins> // revisions: explicit implicit //[implicit] check-pass #![forbid(coherence_leak_check)] #![feature(negative_impls, with_negative_coherence)] pub trait Marker {} #[cfg(implicit)] impl<T: ?Sized> !Marker for &T {} #[cfg(explicit)] impl<'a, T: ?Sized + 'a> !Marker for &'a T {} trait FnMarker {} // Unifying these two impls below results in a `T: '!0` obligation // that we shouldn't need to care about. Ideally, we'd treat that // as an assumption when proving `&'!0 T: Marker`... impl<T: ?Sized + Marker> FnMarker for fn(T) {} impl<T: ?Sized> FnMarker for fn(&T) {} //[explicit]~^ ERROR conflicting implementations of trait `FnMarker` for type `fn(&_)` //[explicit]~| WARN this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: The same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing

let (param_env, unevaluated) = unevaluated.prepare_for_eval(tcx, param_env); // try to resolve e.g. associated constants to their definition on an impl, and then // evaluate the const. <del> let c = tcx.const_eval_resolve_for_typeck(param_env, unevaluated, span)?; Ok(c.expect("`ty::Const::eval` called on a non-valtree-compatible type")) </del> <ins> let Some(c) = tcx.const_eval_resolve_for_typeck(param_env, unevaluated, span)? else { // This can happen when we run on ill-typed code. let e = tcx.sess.span_delayed_bug( span.unwrap_or(DUMMY_SP), "`ty::Const::eval` called on a non-valtree-compatible type", ); return Err(e.into()); }; Ok(c) </ins> } ConstKind::Value(val) => Ok(val), ConstKind::Error(g) => Err(g.into()),