jiebi/CodeConvo huggingface dataset:
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: // Only "class" methods are generally understood by LLVM, // so avoid methods on other types (e.g., `<*mut T>::null`). <del> match impl_self_ty.kind() { ty::Adt(def, ..) if !def.is_box() => { // Again, only create type information if full debuginfo is enabled if cx.sess().opts.debuginfo == DebugInfo::Full && !impl_self_ty.has_param() { Some(type_di_node(cx, impl_self_ty)) } else { Some(namespace::item_namespace(cx, def.did())) } </del> <ins> if let ty::Adt(def, ..) = impl_self_ty.kind() && !def.is_box() { // Again, only create type information if full debuginfo is enabled if cx.sess().opts.debuginfo == DebugInfo::Full && !impl_self_ty.has_param() { return (type_di_node(cx, impl_self_ty), true); } else { return (namespace::item_namespace(cx, def.did()), false); </ins> } <del> _ => None, </del> } } else { // For trait method impls we still use the "parallel namespace" // strategy <del> None </del> } <del> }); </del> <ins> } </ins> <del> self_type.unwrap_or_else(|| { namespace::item_namespace( cx, DefId { krate: instance.def_id().krate, index: cx .tcx .def_key(instance.def_id()) .parent .expect("get_containing_scope: missing parent?"), }, ) }) </del> <ins> let scope = namespace::item_namespace( cx, DefId { krate: instance.def_id().krate, index: cx .tcx .def_key(instance.def_id()) .parent .expect("get_containing_scope: missing parent?"), }, ); (scope, false) </ins> } }
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: Decl: Option<&'a DIDescriptor>, ) -> &'a DISubprogram; <ins> pub fn LLVMRustDIBuilderCreateMethod<'a>( Builder: &DIBuilder<'a>, Scope: &'a DIDescriptor, Name: *const c_char, NameLen: size_t, LinkageName: *const c_char, LinkageNameLen: size_t, File: &'a DIFile, LineNo: c_uint, Ty: &'a DIType, Flags: DIFlags, SPFlags: DISPFlags, TParam: &'a DIArray, ) -> &'a DISubprogram; </ins> pub fn LLVMRustDIBuilderCreateBasicType<'a>( Builder: &DIBuilder<'a>, Name: *const c_char,
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: return wrap(Sub); } <ins> extern "C" LLVMMetadataRef LLVMRustDIBuilderCreateMethod( LLVMRustDIBuilderRef Builder, LLVMMetadataRef Scope, const char *Name, size_t NameLen, const char *LinkageName, size_t LinkageNameLen, LLVMMetadataRef File, unsigned LineNo, LLVMMetadataRef Ty, LLVMRustDIFlags Flags, LLVMRustDISPFlags SPFlags, LLVMMetadataRef TParam) { DITemplateParameterArray TParams = DITemplateParameterArray(unwrap<MDTuple>(TParam)); DISubprogram::DISPFlags llvmSPFlags = fromRust(SPFlags); DINode::DIFlags llvmFlags = fromRust(Flags); DISubprogram *Sub = Builder->createMethod( unwrapDI<DIScope>(Scope), StringRef(Name, NameLen), StringRef(LinkageName, LinkageNameLen), unwrapDI<DIFile>(File), LineNo, unwrapDI<DISubroutineType>(Ty), 0, 0, nullptr, // VTable params aren't used llvmFlags, llvmSPFlags, TParams); return wrap(Sub); } </ins> extern "C" LLVMMetadataRef LLVMRustDIBuilderCreateBasicType( LLVMRustDIBuilderRef Builder, const char *Name, size_t NameLen, uint64_t SizeInBits, unsigned Encoding) {
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: <ins> # ignore-cross-compile include ../tools.mk # With the upgrade to LLVM 16, this was getting: # #   error: Cannot represent a difference across sections # # The error stemmed from DI function definitions under type scopes, fixed by # only declaring in type scope and defining the subprogram elsewhere. all: $(RUSTC) lib.rs --test -C lto=fat -C debuginfo=2 -C incremental=$(TMPDIR)/inc-fat </ins>
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: <ins> extern crate alloc; #[cfg(test)] mod tests { #[test] fn something_alloc() { assert_eq!(Vec::<u32>::new(), Vec::<u32>::new()); } } </ins>
Code change:
The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks

Related discussion:
text: /// use std::sync::Arc; /// use std::task::{Context, Poll, Wake}; /// use std::thread::{self, Thread}; <ins> /// use core::pin::pin; </ins> /// /// /// A waker that wakes up the current thread when called. /// struct ThreadWaker(Thread);
Code change:
The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks

Related discussion:
text: /// /// Run a future to completion on the current thread. /// fn block_on<T>(fut: impl Future<Output = T>) -> T { ///     // Pin the future so it can be polled. <del> ///     let mut fut = Box::pin(fut); </del> <ins> ///     let mut fut = pin!(fut); </ins> /// ///     // Create a new context to be passed to the future. ///     let t = thread::current();
Code change:
While logged in as on Linux:: the Rust repo The suggestion to run isn't helpful if you don't already have a Rust toolchain installed. That leaves: "Alternatively, use the pre-vendored dist component." It's completely unclear to me what this means or how to do it. Perhaps providing a link to documentation would be useful. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh this is very funny, is what rustup calls it, which is of course completely unhelpful in this scenario where you don't have rustup and are building from source. Mentoring instructions: should link to
Hmm, I guess for this particular scenario you might be building from a commit other than latest master as well. We do technically package it for individual commits: but AFAIK that isn't documented anywhere. Maybe we should add it to forge?
claim
hello, i'm taking the liberty of claiming this pull request, but I'd like some information. Should I propose a solution (like the curl command with the right url?) or just propose the documentation page?
claim
claim

Related discussion:
text: eprint('ERROR: vendoring required, but vendor directory does not exist.') eprint('       Run `cargo vendor {}` to initialize the ' 'vendor directory.'.format(sync_dirs)) <del> eprint('Alternatively, use the pre-vendored `rustc-src` dist component.') </del> <ins> eprint('       Alternatively, use the pre-vendored `rustc-src` dist component.') eprint('       To get a stable/beta/nightly version, download it from: ') eprint('       ' 'https://forge.rust-lang.org/infra/other-installation-methods.html#source-code') eprint('       To get a specific commit version, download it using the below URL,') eprint('       replacing <commit> with a specific commit checksum: ') eprint('       ' 'https://ci-artifacts.rust-lang.org/rustc-builds/<commit>/rustc-nightly-src.tar.xz') eprint('       Once you have the source downloaded, place the vendor directory') eprint('       from the archive in the root of the rust project.') </ins> raise Exception("{} not found".format(vendor_dir)) if not os.path.exists(cargo_dir):
Code change:
I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.

Related discussion:
text: Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/109373 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/96971 </ins>
Code change:
I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at

Related discussion:
text: <ins> // run-fail // check-run-results // exec-env:RUST_BACKTRACE=0 // Test that we format the panic message only once. // Regression test for https://github.com/rust-lang/rust/issues/110717 use std::fmt; struct PrintOnFmt; impl fmt::Display for PrintOnFmt { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { eprintln!("fmt"); f.write_str("PrintOnFmt") } } fn main() { panic!("{}", PrintOnFmt) } </ins>
Code change:
I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at

Related discussion:
text: <ins> fmt thread 'main' panicked at 'PrintOnFmt', $DIR/fmt-only-once.rs:20:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace </ins>
Code change:
Happened during probably since cc
You'll need to delete the directory. There was probably a file left behind, and git won't delete the directory automatically.
Hm, there is no such directory ?! :sweatsmile: There is a though
My fault. I forgot to update Will send a PR.
What is most concerning to me is that this actually did not fail the entire , so this would/did not even break CI..? is there something we can do about that?
Run in CI probably? I supposed to run it locally before submitting a PR. However, that was an unlucky day. Something on nightly cannot build, so I blindly pushed .
Oh, sorry, I misunderstood what was going on. There have been some issues with those directories being moved around, but this was different. The issue here is that the credential helpers are being included on an "as available" basis. Because they are nightly and experimental, they were intentionally marked as being optional so that if they failed it wouldn't cause problems here on rust-lang/rust. Eventually, if it gets stabilized, this will need to change to make them required tools.

Related discussion:
text: if self.target.contains("windows") { build_cred( "cargo-credential-wincred", <del> "src/tools/cargo/crates/credential/cargo-credential-wincred", </del> <ins> "src/tools/cargo/credential/cargo-credential-wincred", </ins> ); } if self.target.contains("apple-darwin") { build_cred( "cargo-credential-macos-keychain", <del> "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", </del> <ins> "src/tools/cargo/credential/cargo-credential-macos-keychain", </ins> ); } build_cred( "cargo-credential-1password", <del> "src/tools/cargo/crates/credential/cargo-credential-1password", </del> <ins> "src/tools/cargo/credential/cargo-credential-1password", </ins> ); cargo_bin_path }
Code change:
There should be a test for ensuring that it does not have the same bug as and , that inside of the const refers to instead of inferring a lifetime. The following code is what passes and should be as a test: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
are you still working on this? If not, I would be happy to claim :slightlysmilingface:
there is no activity from them for almost a month, so you are free to claim it now
claim

Related discussion:
text: <ins> // check-pass #![feature(inline_const)] fn main() { let _my_usize = const { let a = 10_usize; let b: &'_ usize = &a; *b }; } </ins>
Code change:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

Related discussion:
text: } } <del> impl Visitor<'_> for CanConstProp { </del> <ins> impl<'tcx> Visitor<'tcx> for CanConstProp { fn visit_place(&mut self, place: &Place<'tcx>, mut context: PlaceContext, loc: Location) { use rustc_middle::mir::visit::PlaceContext::*; // Dereferencing just read the addess of `place.local`. if place.projection.first() == Some(&PlaceElem::Deref) { context = NonMutatingUse(NonMutatingUseContext::Copy); } self.visit_local(place.local, context, loc); self.visit_projection(place.as_ref(), context, loc); } </ins> fn visit_local(&mut self, local: Local, context: PlaceContext, _: Location) { use rustc_middle::mir::visit::PlaceContext::*; match context { <del> // Projections are fine, because `&mut foo.x` will be caught by // `MutatingUseContext::Borrow` elsewhere. MutatingUse(MutatingUseContext::Projection) </del> // These are just stores, where the storing is not propagatable, but there may be later // mutations of the same local via `Store` | MutatingUse(MutatingUseContext::Call)
Code change:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

Related discussion:
text: NonMutatingUse(NonMutatingUseContext::Copy) | NonMutatingUse(NonMutatingUseContext::Move) | NonMutatingUse(NonMutatingUseContext::Inspect) <del> | NonMutatingUse(NonMutatingUseContext::Projection) </del> | NonMutatingUse(NonMutatingUseContext::PlaceMention) | NonUse(_) => {}