Question:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.

use crate::cmp; <del> use crate::iter::{ adapters::zip::try_get_unchecked, adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen, TrustedRandomAccess, }; </del> <ins> use crate::iter::{adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen}; </ins> use crate::ops::{ControlFlow, Try}; /// An iterator that only iterates over the first `n` iterations of `iter`.


Question:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.

self.try_fold(init, ok(fold)).unwrap() } <del> unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> <I as Iterator>::Item where Self: TrustedRandomAccess, { // SAFETY: the caller must uphold the contract for // `Iterator::__iterator_get_unchecked`. unsafe { try_get_unchecked(&mut self.iter, idx) } } </del> } #[unstable(issue = "none", feature = "inplace_iteration")]


Question:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.

#[unstable(feature = "trusted_len", issue = "37572")] unsafe impl<I: TrustedLen> TrustedLen for Take<I> {} <del> #[doc(hidden)] #[unstable(feature = "trusted_random_access", issue = "none")] unsafe impl<I> TrustedRandomAccess for Take<I> where I: TrustedRandomAccess, { const MAY_HAVE_SIDE_EFFECT: bool = I::MAY_HAVE_SIDE_EFFECT; } </del>


Question:
With on , will not drop the inside , just like does not drop the original before overwriting it. However, a manual implementation of can only make use of the efficiency of a overriden on (e.g. memory reuse by a ) by simply forwarding to it, which means that will not forget the old value. This new (forwarding, so (potentially) dropping) behaviour was in , and (for now) reverted in So question for What behaviour would be correct? There are arguments for both. Whatever the decision, we should document it and add a test for it.
I feel that the old behavior is correct (not calling drop). should behave like which for means not dropping the old value. I don't think there is much loss of efficiency in practice: use of is already pretty rare and I don't think there are any cases of it being used with .
Sounds good. Closing this.
No wait, we still need to do this part. :)

#[test] fn smoke() { <ins> #[derive(Clone)] </ins> struct TypeWithDrop; impl Drop for TypeWithDrop { fn drop(&mut self) {


Question:
With on , will not drop the inside , just like does not drop the original before overwriting it. However, a manual implementation of can only make use of the efficiency of a overriden on (e.g. memory reuse by a ) by simply forwarding to it, which means that will not forget the old value. This new (forwarding, so (potentially) dropping) behaviour was in , and (for now) reverted in So question for What behaviour would be correct? There are arguments for both. Whatever the decision, we should document it and add a test for it.
I feel that the old behavior is correct (not calling drop). should behave like which for means not dropping the old value. I don't think there is much loss of efficiency in practice: use of is already pretty rare and I don't think there are any cases of it being used with .
Sounds good. Closing this.
No wait, we still need to do this part. :)

let x: Box<ManuallyDrop<[TypeWithDrop]>> = Box::new(ManuallyDrop::new([TypeWithDrop, TypeWithDrop])); drop(x); <ins> // test clone and clone_from implementations let mut x = ManuallyDrop::new(TypeWithDrop); let y = x.clone(); x.clone_from(&y); drop(x); drop(y); </ins> }


Question:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.

if let LinkerFlavor::Gcc = flavor { match ld_impl { LdImpl::Lld => { <del> let tools_path = sess.host_filesearch(PathKind::All).get_tools_search_paths(false); let lld_path = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .find(|p| { p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }).exists() }) .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found")); cmd.cmd().arg({ let mut arg = OsString::from("-B"); arg.push(lld_path); arg }); </del> <ins> if sess.target.lld_flavor == LldFlavor::Ld64 { let tools_path = sess.host_filesearch(PathKind::All).get_tools_search_paths(false); let ld64_exe = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .map(|p| { p.join(if sess.host.is_like_windows { "ld64.exe" } else { "ld64" }) }) .find(|p| p.exists()) .unwrap_or_else(|| sess.fatal("rust-lld (as ld64) not found")); cmd.cmd().arg({ let mut arg = OsString::from("-fuse-ld="); arg.push(ld64_exe); arg }); } else { let tools_path = sess.host_filesearch(PathKind::All).get_tools_search_paths(false); let lld_path = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .find(|p| { p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }) .exists() }) .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found")); cmd.cmd().arg({ let mut arg = OsString::from("-B"); arg.push(lld_path); arg }); } </ins> } } } else {


Question:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.

use std::env; <del> use crate::spec::{FramePointer, SplitDebuginfo, TargetOptions}; </del> <ins> use crate::spec::{FramePointer, LldFlavor, SplitDebuginfo, TargetOptions}; </ins> pub fn opts(os: &str) -> TargetOptions { // ELF TLS is only available in macOS 10.7+. If you try to compile for 10.6


Question:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.

abi_return_struct_as_int: true, emit_debug_gdb_scripts: false, eh_frame_header: false, <ins> lld_flavor: LldFlavor::Ld64, </ins> // The historical default for macOS targets is to run `dsymutil` which // generates a packed version of debuginfo split from the main file.


Question:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.

&lld_install.join("bin").join(&src_exe), &gcc_ld_dir.join(exe("ld", target_compiler.host)), ); <ins> builder.copy( &lld_install.join("bin").join(&src_exe), &gcc_ld_dir.join(exe("ld64", target_compiler.host)), ); </ins> } // Similarly, copy `llvm-dwp` into libdir for Split DWARF. Only copy it when the LLVM


Question:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.

let gcc_lld_dir = dst_dir.join("gcc-ld"); t!(fs::create_dir(&gcc_lld_dir)); builder.copy(&src_dir.join(&rust_lld), &gcc_lld_dir.join(exe("ld", compiler.host))); <ins> builder .copy(&src_dir.join(&rust_lld), &gcc_lld_dir.join(exe("ld64", compiler.host))); </ins> } // Copy over llvm-dwp if it's there


Question:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.

padding: 0 20px 20px 17px;; } <ins> .item-info .stab { display: table; } </ins> .stab { border-width: 1px; border-style: solid;


Question:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.

<ins> // This test ensures that the item information don't take 100% of the width if unnecessary. goto: file://|DOC_PATH|/lib2/struct.Foo.html // We set a fixed size so there is no chance of "random" resize. size: (1100, 800) // We check that ".item-info" is bigger than its content. assert-css: (".item-info", {"width": "807px"}) assert-css: (".item-info .stab", {"width": "343px"}) </ins>


Question:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.

// ignore-tidy-linelength <ins> #![feature(doc_cfg)] </ins> pub mod module { pub mod sub_module { pub mod sub_sub_module {


Question:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.

pub type Alias = u32; <ins> #[doc(cfg(feature = "foo-method"))] </ins> pub struct Foo { pub x: Alias, }


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. --Regarding a minimal example I am afraid I'm not quite able to provide one, this bug occured when i was migrating to Rust 2021 as part of the testing efforts. The branch/PR with the Rust 2021 modifications can be found here I did cfgment all modules except the ones that are required to trigger the bug out: And removed most code and modules from the rcc module: , nailing the bug down to (as the error message suggested). Then i minized further in (its 200 lines now, the rest is just tests) And I was in fact able to pin point the panic to this piece of code: , if I comment it out the ICE doesn't occur anymore so I would guess that this is what the compiler is having issues with. <!-- 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. --: Compilation command I used was: <!-- 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 --
Thanks for the report! Here's a somewhat minimized reproduction:
cc
claim

} } } <del> PatKind::Lit(_) => { // If the PatKind is a Lit then we want </del> <ins> PatKind::Lit(_) | PatKind::Range(..) => { // If the PatKind is a Lit or a Range then we want </ins> // to borrow discr. needs_to_be_read = true; } <del> _ => {} </del> <ins> PatKind::Or(_) | PatKind::Box(_) | PatKind::Slice(..) | PatKind::Ref(..) | PatKind::Wild => { // If the PatKind is Or, Box, Slice or Ref, the decision is made later // as these patterns contains subpatterns // If the PatKind is Wild, the decision is made based on the other patterns being // examined } </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. --Regarding a minimal example I am afraid I'm not quite able to provide one, this bug occured when i was migrating to Rust 2021 as part of the testing efforts. The branch/PR with the Rust 2021 modifications can be found here I did cfgment all modules except the ones that are required to trigger the bug out: And removed most code and modules from the rcc module: , nailing the bug down to (as the error message suggested). Then i minized further in (its 200 lines now, the rest is just tests) And I was in fact able to pin point the panic to this piece of code: , if I comment it out the ICE doesn't occur anymore so I would guess that this is what the compiler is having issues with. <!-- 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. --: Compilation command I used was: <!-- 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 --
Thanks for the report! Here's a somewhat minimized reproduction:
cc
claim

<ins> // run-pass // edition:2021 pub fn foo() { let ref_x_ck = 123; let _y = || match ref_x_ck { 2_000_000..=3_999_999 => { println!("A")} _ => { println!("B")} }; } fn main() { foo(); } </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly

let mut err = match *error { SelectionError::Unimplemented => { <del> // If this obligation was generated as a result of well-formed checking, see if we // can get a better error message by performing HIR-based well formed checking. </del> <ins> // If this obligation was generated as a result of well-formedness checking, see if we // can get a better error message by performing HIR-based well-formedness checking. </ins> if let ObligationCauseCode::WellFormed(Some(wf_loc)) = root_obligation.cause.code.peel_derives() {


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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly

// given the type `Option<MyStruct<u8>>`, we will check // `Option<MyStruct<u8>>`, `MyStruct<u8>`, and `u8`. // For each type, we perform a well-formed check, and see if we get <del> // an erorr that matches our expected predicate. We keep save </del> <ins> // an error that matches our expected predicate. We save </ins> // the `ObligationCause` corresponding to the *innermost* type, // which is the most specific type that we can point to. // In general, the different components of an `hir::Ty` may have <del> // completely differentr spans due to macro invocations. Pointing </del> <ins> // completely different spans due to macro invocations. Pointing </ins> // to the most accurate part of the type can be the difference // between a useless span (e.g. the macro invocation site) <del> // and a useful span (e.g. a user-provided type passed in to the macro). </del> <ins> // and a useful span (e.g. a user-provided type passed into the macro). </ins> // // This approach is quite inefficient - we redo a lot of work done // by the normal WF checker. However, this code is run at most once // per reported error - it will have no impact when compilation succeeds, <del> // and should only have an impact if a very large number of errors are // displaydd to the user. </del> <ins> // and should only have an impact if a very large number of errors is // displayed to the user. </ins> struct HirWfCheck<'tcx> { tcx: TyCtxt<'tcx>, predicate: ty::Predicate<'tcx>,


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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly

WellFormedLoc::Ty(_) => match hir.get(hir_id) { hir::Node::ImplItem(item) => match item.kind { hir::ImplItemKind::TyAlias(ty) => Some(ty), <ins> hir::ImplItemKind::Const(ty, _) => Some(ty), </ins> ref item => bug!("Unexpected ImplItem {:?}", item), }, hir::Node::TraitItem(item) => match item.kind { hir::TraitItemKind::Type(_, ty) => ty, <ins> hir::TraitItemKind::Const(ty, _) => Some(ty), </ins> ref item => bug!("Unexpected TraitItem {:?}", item), }, hir::Node::Item(item) => match item.kind {


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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly

<ins> // Regression test for the ICE described in #87495. trait T { const CONST: (bool, dyn T); //~^ ERROR: the trait `T` cannot be made into an object [E0038] } 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly

<ins> error[E0038]: the trait `T` cannot be made into an object --> $DIR/issue-87495.rs:4:25 | LL |     const CONST: (bool, dyn T); |                         ^^^^^ `T` cannot be made into an object | = help: consider moving `CONST` to another trait note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/issue-87495.rs:4:11 | LL | trait T { |       - this trait cannot be made into an object... LL |     const CONST: (bool, dyn T); |           ^^^^^ ...because it contains this associated `const` error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. </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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :

if let ObligationCauseCode::WellFormed(Some(wf_loc)) = root_obligation.cause.code.peel_derives() { <del> if let Some(cause) = self.tcx.diagnostic_hir_wf_check((obligation.predicate, wf_loc.clone())) { </del> <ins> if let Some(cause) = self.tcx.diagnostic_hir_wf_check(( tcx.erase_regions(obligation.predicate), wf_loc.clone(), )) { </ins> obligation.cause = cause; span = obligation.cause.span; }


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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :

<ins> // Regression test for #87549. // compile-flags: -C incremental=tmp/wf/hir-wf-check-erase-regions pub struct Table<T, const N: usize>([Option<T>; N]); impl<'a, T, const N: usize> IntoIterator for &'a Table<T, N> { type IntoIter = std::iter::Flatten<std::slice::Iter<'a, T>>; //~ ERROR `&T` is not an iterator type Item = &'a T; fn into_iter(self) -> Self::IntoIter { //~ ERROR `&T` is not an iterator unimplemented!() } } 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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :

<ins> error[E0277]: `&T` is not an iterator --> $DIR/hir-wf-check-erase-regions.rs:7:5 | LL |     type IntoIter = std::iter::Flatten<std::slice::Iter<'a, T>>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `&T` is not an iterator | ::: $SRC_DIR/core/src/iter/adapters/flatten.rs:LL:COL | LL | pub struct Flatten<I: Iterator<Item: IntoIterator>> { |                                      ------------ required by this bound in `Flatten` | = help: the trait `Iterator` is not implemented for `&T` = note: required because of the requirements on the impl of `IntoIterator` for `&T` error[E0277]: `&T` is not an iterator --> $DIR/hir-wf-check-erase-regions.rs:10:27 | LL |     fn into_iter(self) -> Self::IntoIter { |                           ^^^^^^^^^^^^^^ `&T` is not an iterator | ::: $SRC_DIR/core/src/iter/adapters/flatten.rs:LL:COL | LL | pub struct Flatten<I: Iterator<Item: IntoIterator>> { |                                      ------------ required by this bound in `Flatten` | = help: the trait `Iterator` is not implemented for `&T` = note: required because of the requirements on the impl of `IntoIterator` for `&T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>


Question:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

if def.variants.len() > 1 { needs_to_be_read = true; } <ins> } else { // If it is not ty::Adt, then it should be read needs_to_be_read = true; </ins> } } PatKind::Lit(_) | PatKind::Range(..) => {


Question:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> // run-pass // edition:2021 const LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED: i32 = 0x01; const LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT: i32 = 0x02; pub fn hotplug_callback(event: i32) { let _ = || { match event { LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED => (), LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT => (), _ => (), }; }; } fn main() { hotplug_callback(1); } </ins>


Question:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> // run-pass // edition:2021 const PATTERN_REF: &str = "Hello World"; const NUMBER: i32 = 30; const NUMBER_POINTER: *const i32 = &NUMBER; pub fn edge_case_ref(event: &str) { let _ = || { match event { PATTERN_REF => (), _ => (), }; }; } pub fn edge_case_str(event: String) { let _ = || { match event.as_str() { "hello" => (), _ => (), }; }; } pub fn edge_case_raw_ptr(event: *const i32) { let _ = || { match event { NUMBER_POINTER => (), _ => (), }; }; } pub fn edge_case_char(event: char) { let _ = || { match event { 'a' => (), _ => (), }; }; } fn main() {} </ins>


Question:
The following is minimized from , which is regressed as of nightly-2021-08-15.
Relevant commit range is Of the 9 landed PRs, the ones that look potentially relevant to codegen are and .
I tried all the merge commits in order of merge: : pass : pass : pass : pass : pass : pass : pass : pass : regressed so that narrows this down to (
This passes under Miri, so I suspect that we've exposed an LLVM bug.
Not sure it's an LLVM bug because it seems the IR is broken even before any LLVM passes. I tried: Before: After: Diff: The looks like legitimately broken input IR. Notice the extractvalue insts relocated from the front of bb4 to the end of bb0 (invalidly after the terminator). What in LLVM is actually running during a -Cno-prepopulate-passes build?
I think we should do a quick revert and then figure this out without any pressure
the mir changes are that seems totally reasonable, so we need to check what codegen_llvm makes of it
I wonder why the goto collapse only happens if the zst assignment is eliminated. it seems like we need to preserve bb4 in mir or inject it in codegen_llvm, but first we should find out why the goto collapse is happening at all
There are no control-flow simplification passes after removal of dead local variables, which is why it didn't happen so far. Still, it seems a bit surprising it wasn't reported earlier: Adding a new cleanup pass before codegen would be one way to address this.
I swear half of my PRs break the compiler I'm excited for what bugs arise when we start using undef for uninitialized consts... Revert PR:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
The issue was not fixed, it is an LLVM crash on stable as shows
Relabeling regression because worked in 1.51.0. It bisects to nightly-2021-03-02 ().
is the only codegen change in that nightly.
Reopening to track the stable-to-stable regression.
Backport was merged.

impl AddCallGuards { pub fn add_call_guards(&self, body: &mut Body<'_>) { <del> let pred_count: IndexVec<_, _> = body.predecessors().iter().map(|ps| ps.len()).collect(); </del> <ins> let mut pred_count: IndexVec<_, _> = body.predecessors().iter().map(|ps| ps.len()).collect(); pred_count[START_BLOCK] += 1; </ins> // We need a place to store the new blocks generated let mut new_blocks = Vec::new();


Question:
The following is minimized from , which is regressed as of nightly-2021-08-15.
Relevant commit range is Of the 9 landed PRs, the ones that look potentially relevant to codegen are and .
I tried all the merge commits in order of merge: : pass : pass : pass : pass : pass : pass : pass : pass : regressed so that narrows this down to (
This passes under Miri, so I suspect that we've exposed an LLVM bug.
Not sure it's an LLVM bug because it seems the IR is broken even before any LLVM passes. I tried: Before: After: Diff: The looks like legitimately broken input IR. Notice the extractvalue insts relocated from the front of bb4 to the end of bb0 (invalidly after the terminator). What in LLVM is actually running during a -Cno-prepopulate-passes build?
I think we should do a quick revert and then figure this out without any pressure
the mir changes are that seems totally reasonable, so we need to check what codegen_llvm makes of it
I wonder why the goto collapse only happens if the zst assignment is eliminated. it seems like we need to preserve bb4 in mir or inject it in codegen_llvm, but first we should find out why the goto collapse is happening at all
There are no control-flow simplification passes after removal of dead local variables, which is why it didn't happen so far. Still, it seems a bit surprising it wasn't reported earlier: Adding a new cleanup pass before codegen would be one way to address this.
I swear half of my PRs break the compiler I'm excited for what bugs arise when we start using undef for uninitialized consts... Revert PR:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
The issue was not fixed, it is an LLVM crash on stable as shows
Relabeling regression because worked in 1.51.0. It bisects to nightly-2021-03-02 ().
is the only codegen change in that nightly.
Reopening to track the stable-to-stable regression.
Backport was merged.

// CHECK-LABEL: @main fn main() { take_until(|| true); <ins> f(None); </ins> } <ins> fn f(_a: Option<String>) -> Option<u32> { loop { g(); () } } fn g() -> Option<u32> { None } </ins>


Question:
fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:

if let Some(hir::Guard::If(ref e)) = arm.guard { self.consume_expr(e) <ins> } else if let Some(hir::Guard::IfLet(_, ref e)) = arm.guard { self.consume_expr(e) </ins> } self.consume_expr(&arm.body);


Question:
fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:

<ins> // edition:2021 // run-pass #![feature(if_let_guard)] #[allow(unused_must_use)] #[allow(dead_code)] fn print_error_count(registry: &Registry) { |x: &Registry| { match &x { Registry if let _ = registry.try_find_description() => { } //~^ WARNING: irrefutable `if let` guard pattern _ => {} } }; } struct Registry; impl Registry { pub fn try_find_description(&self) { unimplemented!() } } fn main() {} </ins>


Question:
fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:

<ins> warning: irrefutable `if let` guard pattern --> $DIR/issue-88118-2.rs:10:29 | LL |             Registry if let _ = registry.try_find_description() => { } |                             ^ | = note: `#[warn(irrefutable_let_patterns)]` on by default = note: this pattern will always match, so the guard is useless = help: consider removing the guard and adding a `let` inside the match arm warning: 1 warning emitted </ins>


Question:
Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

} fn check_fn_decl(&self, fn_decl: &FnDecl, self_semantic: SelfSemantic) { <ins> self.check_decl_num_args(fn_decl); </ins> self.check_decl_cvaradic_pos(fn_decl); self.check_decl_attrs(fn_decl); self.check_decl_self_param(fn_decl, self_semantic); } <ins> /// Emits fatal error if function declaration has more than `u16::MAX` arguments /// Error is fatal to prevent errors during typechecking fn check_decl_num_args(&self, fn_decl: &FnDecl) { let max_num_args: usize = u16::MAX.into(); if fn_decl.inputs.len() > max_num_args { let Param { span, .. } = fn_decl.inputs[0]; self.err_handler().span_fatal( span, &format!("function can not have more than {} arguments", max_num_args), ); } } </ins> fn check_decl_cvaradic_pos(&self, fn_decl: &FnDecl) { match &*fn_decl.inputs { [Param { ty, span, .. }] => {


Question:
Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

<ins> macro_rules! many_args { ([$($t:tt)*]#$($h:tt)*) => { many_args!{[$($t)*$($t)*]$($h)*} }; ([$($t:tt)*]) => { fn _f($($t: ()),*) {} //~ ERROR function can not have more than 65535 arguments } } many_args!{[_]########## ######} fn main() {} </ins>


Question:
Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

<ins> error: function can not have more than 65535 arguments --> $DIR/issue-88577-check-fn-with-more-than-65535-arguments.rs:6:24 | LL |           fn _f($($t: ()),*) {} |  ________________________^ LL | |     } LL | | } LL | | LL | | many_args!{[_]########## ######} | |____________^ 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

struct_span_err!(sess, sp, E0004, "{}", &error_message) } <ins> #[derive(PartialEq)] enum RefutableFlag { Irrefutable, Refutable, } use RefutableFlag::*; </ins> struct MatchVisitor<'a, 'p, 'tcx> { tcx: TyCtxt<'tcx>, typeck_results: &'a ty::TypeckResults<'tcx>,


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

hir::LocalSource::AssignDesugar(_) => ("destructuring assignment binding", None), }; self.check_irrefutable(&loc.pat, msg, sp); <del> self.check_patterns(&loc.pat); </del> <ins> self.check_patterns(&loc.pat, Irrefutable); </ins> } fn visit_param(&mut self, param: &'tcx hir::Param<'tcx>) { intravisit::walk_param(self, param); self.check_irrefutable(&param.pat, "function argument", None); <del> self.check_patterns(&param.pat); </del> <ins> self.check_patterns(&param.pat, Irrefutable); </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

} impl<'p, 'tcx> MatchVisitor<'_, 'p, 'tcx> { <del> fn check_patterns(&self, pat: &Pat<'_>) { </del> <ins> fn check_patterns(&self, pat: &Pat<'_>, rf: RefutableFlag) { </ins> pat.walk_always(|pat| check_borrow_conflicts_in_at_patterns(self, pat)); <del> check_for_bindings_named_same_as_variants(self, pat); </del> <ins> check_for_bindings_named_same_as_variants(self, pat, rf); </ins> } fn lower_pattern(


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

} fn check_let(&mut self, pat: &'tcx hir::Pat<'tcx>, expr: &hir::Expr<'_>, span: Span) { <del> self.check_patterns(pat); </del> <ins> self.check_patterns(pat, Refutable); </ins> let mut cx = self.new_cx(expr.hir_id); let tpat = self.lower_pattern(&mut cx, pat, &mut false); check_let_reachability(&mut cx, pat.hir_id, tpat, span);


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

for arm in arms { // Check the arm for some things unrelated to exhaustiveness. <del> self.check_patterns(&arm.pat); </del> <ins> self.check_patterns(&arm.pat, Refutable); </ins> if let Some(hir::Guard::IfLet(ref pat, _)) = arm.guard { <del> self.check_patterns(pat); </del> <ins> self.check_patterns(pat, Refutable); </ins> let tpat = self.lower_pattern(&mut cx, pat, &mut false); check_let_reachability(&mut cx, pat.hir_id, tpat, tpat.span()); }


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

} } <del> fn check_for_bindings_named_same_as_variants(cx: &MatchVisitor<'_, '_, '_>, pat: &Pat<'_>) { </del> <ins> fn check_for_bindings_named_same_as_variants( cx: &MatchVisitor<'_, '_, '_>, pat: &Pat<'_>, rf: RefutableFlag, ) { </ins> pat.walk_always(|p| { if let hir::PatKind::Binding(_, _, ident, None) = p.kind { if let Some(ty::BindByValue(hir::Mutability::Not)) =


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

variant.ident == ident && variant.ctor_kind == CtorKind::Const }) { <ins> let variant_count = edef.variants.len(); </ins> cx.tcx.struct_span_lint_hir( BINDINGS_WITH_VARIANT_NAME, p.hir_id, p.span, |lint| { let ty_path = cx.tcx.def_path_str(edef.did); <del> lint.build(&format!( </del> <ins> let mut err = lint.build(&format!( </ins> "pattern binding `{}` is named the same as one  <del> of the variants of the type `{}`", </del> <ins> of the variants of the type `{}`", </ins> ident, ty_path <del> )) .code(error_code!(E0170)) .span_suggestion( p.span, "to match on the variant, qualify the path", format!("{}::{}", ty_path, ident), Applicability::MachineApplicable, ) .emit(); </del> <ins> )); err.code(error_code!(E0170)); // If this is an irrefutable pattern, and there's > 1 variant, // then we can't actually match on this. Applying the below // suggestion would produce code that breaks on `check_irrefutable`. if rf == Refutable || variant_count == 1 { err.span_suggestion( p.span, "to match on the variant, qualify the path", format!("{}::{}", ty_path, ident), Applicability::MachineApplicable, ); } err.emit(); </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

<ins> #![allow(unused, nonstandard_style)] #![deny(bindings_with_variant_name)] // If an enum has two different variants, // then it cannot be matched upon in a function argument. // It still gets a warning, but no suggestions. enum Foo { C, D, } fn foo(C: Foo) {} //~ERROR fn main() { let C = Foo::D; //~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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

<ins> error[E0170]: pattern binding `C` is named the same as one of the variants of the type `Foo` --> $DIR/issue-88730.rs:12:8 | LL | fn foo(C: Foo) {} |        ^ | note: the lint level is defined here --> $DIR/issue-88730.rs:2:9 | LL | #![deny(bindings_with_variant_name)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0170]: pattern binding `C` is named the same as one of the variants of the type `Foo` --> $DIR/issue-88730.rs:15:9 | LL |     let C = Foo::D; |         ^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0170`. </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

if self.not_enough_args_provided() { self.suggest_adding_args(err); } else if self.too_many_args_provided() { <ins> self.suggest_moving_args_from_assoc_fn_to_trait(err); </ins> self.suggest_removing_args_or_generics(err); } else { unreachable!();


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

} } <ins> /// Suggests moving redundant argument(s) of an associate function to the /// trait it belongs to. /// /// ```compile_fail /// Into::into::<Option<_>>(42) // suggests considering `Into::<Option<_>>::into(42)` /// ``` fn suggest_moving_args_from_assoc_fn_to_trait(&self, err: &mut Diagnostic) { let trait_ = match self.tcx.trait_of_item(self.def_id) { Some(def_id) => def_id, None => return, }; // Skip suggestion when the associated function is itself generic, it is unclear // how to split the provided parameters between those to suggest to the trait and // those to remain on the associated type. let num_assoc_fn_expected_args = self.num_expected_type_or_const_args() + self.num_expected_lifetime_args(); if num_assoc_fn_expected_args > 0 { return; } let num_assoc_fn_excess_args = self.num_excess_type_or_const_args() + self.num_excess_lifetime_args(); let trait_generics = self.tcx.generics_of(trait_); let num_trait_generics_except_self = trait_generics.count() - if trait_generics.has_self { 1 } else { 0 }; let msg = format!( "consider moving {these} generic argument{s} to the `{name}` trait, which takes up to {num} argument{s}", these = pluralize!("this", num_assoc_fn_excess_args), s = pluralize!(num_assoc_fn_excess_args), name = self.tcx.item_name(trait_), num = num_trait_generics_except_self, ); if let Some(hir_id) = self.path_segment.hir_id && let Some(parent_node) = self.tcx.hir().find_parent_node(hir_id) && let Some(parent_node) = self.tcx.hir().find(parent_node) && let hir::Node::Expr(expr) = parent_node { match expr.kind { hir::ExprKind::Path(ref qpath) => { self.suggest_moving_args_from_assoc_fn_to_trait_for_qualified_path( err, qpath, msg, num_assoc_fn_excess_args, num_trait_generics_except_self ) }, hir::ExprKind::MethodCall(..) => { self.suggest_moving_args_from_assoc_fn_to_trait_for_method_call( err, trait_, expr, msg, num_assoc_fn_excess_args, num_trait_generics_except_self ) }, _ => return, } } } fn suggest_moving_args_from_assoc_fn_to_trait_for_qualified_path( &self, err: &mut Diagnostic, qpath: &'tcx hir::QPath<'tcx>, msg: String, num_assoc_fn_excess_args: usize, num_trait_generics_except_self: usize, ) { if let hir::QPath::Resolved(_, path) = qpath && let Some(trait_path_segment) = path.segments.get(0) { let num_generic_args_supplied_to_trait = trait_path_segment.args().num_generic_params(); if num_assoc_fn_excess_args == num_trait_generics_except_self - num_generic_args_supplied_to_trait { if let Some(span) = self.gen_args.span_ext() && let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span) { let sugg = vec![ (self.path_segment.ident.span, format!("{}::{}", snippet, self.path_segment.ident)), (span.with_lo(self.path_segment.ident.span.hi()), "".to_owned()) ]; err.multipart_suggestion( msg, sugg, Applicability::MaybeIncorrect ); } } } } fn suggest_moving_args_from_assoc_fn_to_trait_for_method_call( &self, err: &mut Diagnostic, trait_: DefId, expr: &'tcx hir::Expr<'tcx>, msg: String, num_assoc_fn_excess_args: usize, num_trait_generics_except_self: usize, ) { if let hir::ExprKind::MethodCall(_, args, _) = expr.kind { assert_eq!(args.len(), 1); if num_assoc_fn_excess_args == num_trait_generics_except_self { if let Some(gen_args) = self.gen_args.span_ext() && let Ok(gen_args) = self.tcx.sess.source_map().span_to_snippet(gen_args) && let Ok(args) = self.tcx.sess.source_map().span_to_snippet(args[0].span) { let sugg = format!("{}::{}::{}({})", self.tcx.item_name(trait_), gen_args, self.tcx.item_name(self.def_id), args); err.span_suggestion(expr.span, msg, sugg, Applicability::MaybeIncorrect); } } } } </ins> /// Suggests to remove redundant argument(s): /// /// ```text


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

--> $DIR/invalid-const-arg-for-type-param.rs:6:23 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); <del> |                       ^^^^^^^^------ help: remove these generics |                       | |                       expected 0 generic arguments </del> <ins> |                       ^^^^^^^^ expected 0 generic arguments </ins> | note: associated function defined here, with 0 generic parameters --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_into(self) -> Result<T, Self::Error>; |        ^^^^^^^^ <ins> help: consider moving this generic argument to the `TryInto` trait, which takes up to 1 argument | LL |     let _: u32 = TryInto::<32>::try_into(5i32).unwrap(); |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     let _: u32 = 5i32.try_into::<32>().unwrap(); LL +     let _: u32 = 5i32.try_into().unwrap(); | </ins> error[E0599]: no method named `f` found for struct `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:9:7


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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

<ins> use std::convert::TryInto; trait A<T> { fn foo() {} } trait B<T, U> { fn bar() {} } struct S; impl<T> A<T> for S {} impl<T, U> B<T, U> for S {} fn main() { let _ = A::foo::<S>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving this generic argument let _ = B::bar::<S, S>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving these generic arguments let _ = A::<S>::foo::<S>(); //~^ ERROR //~| HELP remove these generics let _ = 42.into::<Option<_>>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving this generic argument } </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

<ins> error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-89064.rs:17:16 | LL |     let _ = A::foo::<S>(); |                ^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-89064.rs:4:8 | LL |     fn foo() {} |        ^^^ help: consider moving this generic argument to the `A` trait, which takes up to 1 argument | LL -     let _ = A::foo::<S>(); LL +     let _ = A::<S>::foo(); | help: remove these generics | LL -     let _ = A::foo::<S>(); LL +     let _ = A::foo(); | error[E0107]: this associated function takes 0 generic arguments but 2 generic arguments were supplied --> $DIR/issue-89064.rs:22:16 | LL |     let _ = B::bar::<S, S>(); |                ^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-89064.rs:8:8 | LL |     fn bar() {} |        ^^^ help: consider moving these generic arguments to the `B` trait, which takes up to 2 arguments | LL -     let _ = B::bar::<S, S>(); LL +     let _ = B::<S, S>::bar(); | help: remove these generics | LL -     let _ = B::bar::<S, S>(); LL +     let _ = B::bar(); | error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-89064.rs:27:21 | LL |     let _ = A::<S>::foo::<S>(); |                     ^^^----- help: remove these generics |                     | |                     expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-89064.rs:4:8 | LL |     fn foo() {} |        ^^^ error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-89064.rs:31:16 | LL |     let _ = 42.into::<Option<_>>(); |                ^^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn into(self) -> T; |        ^^^^ help: consider moving this generic argument to the `Into` trait, which takes up to 1 argument | LL |     let _ = Into::<Option<_>>::into(42); |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     let _ = 42.into::<Option<_>>(); LL +     let _ = 42.into(); | error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0107`. </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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

} impl<'tcx> FieldDef { <del> /// Returns the type of this field. The `subst` is typically obtained /// via the second field of `TyKind::AdtDef`. </del> <ins> /// Returns the type of this field. The resulting type is not normalized. The `subst` is /// typically obtained via the second field of `TyKind::AdtDef`. </ins> pub fn ty(&self, tcx: TyCtxt<'tcx>, subst: SubstsRef<'tcx>) -> Ty<'tcx> { tcx.type_of(self.did).subst(tcx, subst) }


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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

variant.fields.iter().enumerate().filter_map(move |(i, field)| { let ty = field.ty(cx.tcx, substs); <ins> // `field.ty()` doesn't normalize after substituting. let ty = cx.tcx.normalize_erasing_regions(cx.param_env, ty); </ins> let is_visible = adt.is_enum() || field.vis.is_accessible_from(cx.module, cx.tcx); let is_uninhabited = cx.is_uninhabited(ty);


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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

write!(f, "{}", hi) } IntRange(range) => write!(f, "{:?}", range), // Best-effort, will render e.g. `false` as `0..=0` <del> Wildcard | Missing { .. } | NonExhaustive => write!(f, "_"), </del> <ins> Wildcard | Missing { .. } | NonExhaustive => write!(f, "_ : {:?}", self.ty), </ins> Or => { for pat in self.iter_fields() { write!(f, "{}{:?}", start_or_continue(" | "), pat)?;


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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

assert!(rows.iter().all(|r| r.len() == v.len())); <del> // FIXME(Nadrieril): Hack to work around type normalization issues (see #72476). let ty = matrix.heads().next().map_or(v.head().ty(), |r| r.ty()); </del> <ins> let ty = v.head().ty(); </ins> let is_non_exhaustive = cx.is_foreign_non_exhaustive_enum(ty); let pcx = PatCtxt { cx, ty, span: v.head().span(), is_top_level, is_non_exhaustive };


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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

<ins> // check-pass // From https://github.com/rust-lang/rust/issues/72476 // and https://github.com/rust-lang/rust/issues/89393 trait Trait { type Projection; } struct A; impl Trait for A { type Projection = bool; } struct B; impl Trait for B { type Projection = (u32, u32); } struct Next<T: Trait>(T::Projection); fn foo1(item: Next<A>) { match item { Next(true) => {} Next(false) => {} } } fn foo2(x: <A as Trait>::Projection) { match x { true => {} false => {} } } fn foo3(x: Next<B>) { let Next((_, _)) = x; match x { Next((_, _)) => {} } } fn foo4(x: <B as Trait>::Projection) { let (_, _) = x; match x { (_, _) => {} } } fn foo5<T: Trait>(x: <T as Trait>::Projection) { match x { _ => {} } } 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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

<del> // check-pass // From https://github.com/rust-lang/rust/issues/72476 trait A { type Projection; } impl A for () { type Projection = bool; } struct Next<T: A>(T::Projection); fn f(item: Next<()>) { match item { Next(true) => {} Next(false) => {} } } fn main() {} </del>


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Test failures are fixed in rust-lang/miri; all this needs is a submodule sync.

<del> Subproject commit 18667a856596713fc4479f99b96afc7f03aa995c </del> <ins> Subproject commit fa91a89193d26e6a86e2eee1cbaa38cb28ccebe1 </ins>


Question:
The test fails due to an arithmetic overflow when debug assertions are enabled. The offending code likely intends to use the explicit wrapping math methods, as the test does pass with the overflow. The test was implemented in <details<summaryBacktrace</summary<p</p</details
The overflowing code is To me, it actually seems like the overflow might be a bug. it looks like you this code. Is it incorrect for it to be overflowing?
This is introduced in with guards like near call-site. So I suppose just swapping the order should be sufficient?
Overflowing here is a bug. Given that we haven't seen an index out of bound panics on like 562, I would guess that the actual logic here is correct (so, we underflow, then overflow). I do want to prove to myself that again (and put it in a comment).
If it is really intended then should be used.
Oh, I think I ran into this as well and thought it was due to a local change I had made violating an invariant.
Duplicate of ?
no, that issue is in diagnostics, while this one is in trait resolution. I'll try to get to the diagnostics issue next week
label -I-prioritize
Ah my bad, thanks. I think I've been running in to both issues and conflating them.

fn universe_for(&mut self, debruijn: ty::DebruijnIndex) -> ty::UniverseIndex { let infcx = self.infcx; let index = <del> self.universe_indices.len() - debruijn.as_usize() + self.current_index.as_usize() - 1; </del> <ins> self.universe_indices.len() + self.current_index.as_usize() - debruijn.as_usize() - 1; </ins> let universe = self.universe_indices[index].unwrap_or_else(|| { for i in self.universe_indices.iter_mut().take(index + 1) { *i = i.or_else(|| Some(infcx.create_next_universe()))


Question:
removed from to make it : We can't do these checks at compile-time, since , for example, involves ptr-int cast to check the alignment: So, as the FIXME suggests, we should enable the checks only at runtime. Recently intrinsic , it allows for exactly this use case - running different code in CTFE and runtime. cc and (it seems like use of requires approval of all of the above teams) label +T-lang +T-libs +A-const-eval +A-const-fn <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Did you intend to nominate this for lang, or for libs?
kinda both: lang: for whether constevalselect is ok in general libs: whether we should start using it in stable const fn
As the assigned reviewer on , and per some of the discussion in today's T-libs meeting, it feels like it would be good to have a more thorough writeup from or someone else on wg-const-eval about what is being asked here. In particular, "lang: for whether constevalselect is ok in general" seems like a question best asked with a considerable amount of context lacking in this issue, perhaps even RFC-like text targeted at the T-lang audience. While I'm not on T-lang, I definitely couldn't make a decision without that document on what the requirements for its usage should be, and this currently doesn't place it into that context. It also seems like the question is better suited to a tracking issue (or perhaps ideally the PR adding it, rather than this issue), but that's a separate question. I imagine a similar level of context would be helpful on the libs side as well, but again, not on that team either.
Thanks for the very kind way of informing me that I was writing useless comments again. I should know better, I do know better, but idk... Anyway: The intrinsic (initially considered as a solution to , but also useful in several other situations), allows calling one of two different functions, where the function is chosen depending on whether we are const evaluating or not. This allows you to write code that behaves differently between runtime and compile-time, and we have no way of checking whether that happened. You are not allowed to use the intrinsic to actually do that though. Both code paths should behave exactly the same, but you may make the const-eval path slower or otherwise different so that it can actually be const evaluated, without losing runtime performance. Notable examples of where it would be ok to use them as far as is concerned: implementing SIMD or platform intrinsics, where the const-eval part is just a slow, pure-Rust version of the same logic skipping pointer alignment or other pointer math checks that are going to get checked by the const eval machinery anyway unsure yet: avoiding debug! and dbg! statements at compile-time (or having a different mechanism entirely for reporting them) There are no plans to expose such behaviour to users at present, this is solely for libstd/libcore implementations. The intrinsic itself (from a runtime perspective) is a trivial type-safe function and completely written in safe Rust code. Its sole magicness comes from being a lang-item that const evaluation intercepts and then chooses to behave differently on. The intrinsic is documented at Do we want to use such behaviour in an easily accessible way in std? Up to now we hid each such case behind a custom intrinsic for just that specific case. Now we have a generic mean to do so. Furthermore, but not relevant this issue, we could in the future, instead of implementing intrinsics like in CTFE wrap it in and have const path execute a regular checked division. Similar changes may simplify the CTFE machinery by transferring some of its logic into libcore Assuming T-lang has no concerns, are you willing to stabilize some const fns that are impossible to stabilize without this. The main concern is that if we ever want to back out of , doing so may require significant work in the CTFE machinery (per function using ) in order to actually remove .
Correction: the const eval machinery does not do pointer alignment checks (Cc ). But if those checks are optional anyway (as is the case here, since these used to be debug assertions), then that is okay.
Note that this does not really save code, since Miri still needs to implement the intrinsics (it will run the run-time path, not the compile-time path). So I am not sure I like this proposal -- having the intrinsic shared between CTFE and Miri gives a lot of coverage to the Miri core engine intrinsic implementation that we would not otherwise get. These comments would probably better fit some consteval_select tracking issue though?
We discussed this in today's meeting. We don't have any issue with adding these checks to or . Also, as general guidance, nobody in the lang team meeting felt that non-observable uses of in this style need direct lang team review. We'd like to see such usages CCed to for review, and cases that wg-const-eval thinks are fine (such as the three "invisible" cases in comment above) seem fine and entirely in the libs domain.
We discussed your question in the libs meeting just now. We're happy with 'low risk' usages of this intrinsic in the standard library, even in stable functions. What counts as 'low risk' we'll leave up to since y'all can best judge what the alternative would look like if would have to be removed.

!ptr.is_null() && ptr as usize % mem::align_of::<T>() == 0 } <ins> /// Checks whether the regions of memory starting at `src` and `dst` of size /// `count * size_of::<T>()` do *not* overlap. #[cfg(debug_assertions)] pub(crate) fn is_nonoverlapping<T>(src: *const T, dst: *const T, count: usize) -> bool { let src_usize = src as usize; let dst_usize = dst as usize; let size = mem::size_of::<T>().checked_mul(count).unwrap(); let diff = if src_usize > dst_usize { src_usize - dst_usize } else { dst_usize - src_usize }; // If the absolute distance between the ptrs is at least as big as the size of the buffer, // they do not overlap. diff >= size } </ins> /// Copies `count * size_of::<T>()` bytes from `src` to `dst`. The source /// and destination must *not* overlap. ///