jiebi/CodeConvo huggingface dataset:
Code change:
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. :)

Related discussion:
text: #[test] fn smoke() { <ins> #[derive(Clone)] </ins> struct TypeWithDrop; impl Drop for TypeWithDrop { fn drop(&mut self) {
Code change:
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. :)

Related discussion:
text: 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> }
Code change:
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.

Related discussion:
text: 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 {
Code change:
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.

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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.
Code change:
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.

Related discussion:
text: &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
Code change:
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.

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: padding: 0 20px 20px 17px;; } <ins> .item-info .stab { display: table; } </ins> .stab { border-width: 1px; border-style: solid;
Code change:
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.

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: // ignore-tidy-linelength <ins> #![feature(doc_cfg)] </ins> pub mod module { pub mod sub_module { pub mod sub_sub_module {
Code change:
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.

Related discussion:
text: pub type Alias = u32; <ins> #[doc(cfg(feature = "foo-method"))] </ins> pub struct Foo { pub x: Alias, }
Code change:
<!-- 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

Related discussion:
text: } } } <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> } })); }
Code change:
<!-- 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

Related discussion:
text: <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>
Code change:
<!-- 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

Related discussion:
text: 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() {
Code change:
<!-- 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

Related discussion:
text: // 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>,
Code change:
<!-- 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

Related discussion:
text: 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 {
Code change:
<!-- 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

Related discussion:
text: <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>