jiebi/CodeConvo huggingface dataset:
Change:
fn main() { let s = ::xcrate::S; <del> //~^ ERROR failed to resolve: could not find `xcrate` in `{{root}}` </del> <ins> //~^ ERROR failed to resolve: could not find `xcrate` in crate root </ins> }

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
assert!(i.is_some()); let _j: P<syntax::ast::Method> = quote_method!(cx, fn foo(&self) {}); <ins> let _k: P<syntax::ast::Method> = quote_method!(cx, #[doc = "hello"] fn foo(&self) {}); </ins> } fn main() {

Discussion:
As of a few weeks ago was able to parse attributes attached to a quoted method. Recently this fails with a syntax error, See example .
I suspect your commit is the culprit here as it removes a from .
Change:
} impl Target { <del> /// Given a function ABI, turn "System" into the correct ABI for this target. </del> <ins> /// Given a function ABI, turn it into the correct ABI for this target. </ins> pub fn adjust_abi(&self, abi: Abi) -> Abi { match abi { Abi::System => {

Discussion:
Compiling code like: results in: presumably because attempts to translate it into an x86-specific ABI, which the AArch64 backend rightly rejects. already ignores for non-x86 targets: I'm not completely sure what the right answer for Rust is. I think is the rough equivalent of the above clang bit and needs to take a few more cases into account for non-x86 Windows: does that sound right? If so, I'll code up a patch.
Sounds like a good place to me!
Change:
} } <ins> /// Waits on this condition variable for a notification, timing out after a /// specified duration.  Spurious wakes will not cause this function to /// return. /// /// The semantics of this function are equivalent to [`wait_until`] except /// that the thread will be blocked for roughly no longer than `dur`. This /// method should not be used for precise timing due to anomalies such as /// preemption or platform differences that may not cause the maximum /// amount of time waited to be precisely `dur`. /// /// Note that the best effort is made to ensure that the time waited is /// measured with a monotonic clock, and not affected by the changes made to /// the system time. /// /// The returned [`WaitTimeoutResult`] value indicates if the timeout is /// known to have elapsed without the condition being met. /// /// Like [`wait_until`], the lock specified will be re-acquired when this /// function returns, regardless of whether the timeout elapsed or not. /// /// [`wait_until`]: #method.wait_until /// [`wait_timeout`]: #method.wait_timeout /// [`WaitTimeoutResult`]: struct.WaitTimeoutResult.html /// /// # Examples /// /// ``` /// use std::sync::{Arc, Mutex, Condvar}; /// use std::thread; /// use std::time::Duration; /// /// let pair = Arc::new((Mutex::new(false), Condvar::new())); /// let pair2 = pair.clone(); /// /// thread::spawn(move|| { ///     let &(ref lock, ref cvar) = &*pair2; ///     let mut started = lock.lock().unwrap(); ///     *started = true; ///     // We notify the condvar that the value has changed. ///     cvar.notify_one(); /// }); /// /// // wait for the thread to start up /// let &(ref lock, ref cvar) = &*pair; /// let result = cvar.wait_timeout_until(lock, Duration::from_millis(100), |started| { ///     started /// }).unwrap(); /// if result.1.timed_out() { ///     // timed-out without the condition ever evaluating to true. /// } /// // access the locked mutex via result.0 /// ``` #[unstable(feature = "wait_timeout_until", issue = "47960")] pub fn wait_timeout_until<'a, T, F>(&self, mut guard: MutexGuard<'a, T>, dur: Duration, mut condition: F) -> LockResult<(MutexGuard<'a, T>, WaitTimeoutResult)> where F: FnMut(&mut T) -> bool { let start = Instant::now(); loop { if condition(&mut *guard) { return Ok((guard, WaitTimeoutResult(false))); } let timeout = match dur.checked_sub(start.elapsed()) { Some(timeout) => timeout, None => return Ok((guard, WaitTimeoutResult(true))), }; guard = self.wait_timeout(guard, timeout)?.0; } } </ins> /// Wakes up one blocked thread on this condvar. /// /// If there is a blocked thread on this condition variable, then it will

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.
Change:
use rustc_errors::{error_code, pluralize, struct_span_err, Applicability}; use rustc_parse::validate_attr; use rustc_session::lint::builtin::PATTERNS_IN_FNS_WITHOUT_BODY; <del> use rustc_session::lint::LintBuffer; </del> <ins> use rustc_session::lint::{BuiltinLintDiagnostics, LintBuffer}; </ins> use rustc_session::Session; use rustc_span::symbol::{kw, sym, Ident}; use rustc_span::Span;

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
Crate { module, primitives, external_traits: cx.external_traits.clone() } } <del> fn external_generic_args( </del> <ins> crate fn substs_to_args( </ins> cx: &mut DocContext<'_>, <del> did: DefId, has_self: bool, bindings: Vec<TypeBinding>, substs: SubstsRef<'_>, ) -> GenericArgs { let mut skip_self = has_self; let mut ty_kind = None; let args: Vec<_> = substs </del> <ins> substs: &[ty::subst::GenericArg<'_>], mut skip_first: bool, ) -> Vec<GenericArg> { substs </ins> .iter() .filter_map(|kind| match kind.unpack() { GenericArgKind::Lifetime(lt) => match *lt {

Discussion:
<!-- 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. --Minimized example: Command: <!-- 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. --Platform: See backtrace <!-- 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 --<!-- TRIAGEBOT_END --
I'll look into it! claim
Minimized this to a local-crate-only test, and working on a solution currently:
Change:
#![cfg_attr(test, feature(test))] #![cfg_attr(test, feature(new_uninit))] #![feature(allocator_api)] <del> #![feature(vec_extend_from_within)] </del> #![feature(array_chunks)] #![feature(array_methods)] #![feature(array_windows)]

Discussion:
Feature gate: This is a tracking issue for , which allows copying elements from a range to the end: <!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [x] Final commenting period (FCP) [x] yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
// Test `ignored_generic_bounds` lint warning about bounds in type aliases. <del> // build-pass (FIXME(62277): could be check-pass?) </del> <ins> // check-pass </ins> #![allow(dead_code)] use std::rc::Rc;

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
match attr::first_attr_value_str_by_name(i.attrs.as_slice(), "link_section") { <del> Some(sect) => unsafe { sect.get().with_c_str(|buf| { llvm::LLVMSetSection(v, buf); }) </del> <ins> Some(sect) => { if contains_null(sect.get()) { ccx.sess().fatal(format!("Illegal null byte in link_section value: `{}`", sect.get()).as_slice()); } unsafe { sect.get().with_c_str(|buf| { llvm::LLVMSetSection(v, buf); }) } </ins> }, None => () }

Discussion:
Both the exportname and linksection attributes will produce an ICE if '0' is contained within the string. Input Output and Bakctrace Version
Fascinating find! I'm curious about what lead you to it. Is there a need to put null in these values?
I had typed rather than . It was an accidental discovery, I'm not aware of any need for a null character here.
I marked this as easy since fixing this is probably just a matter of going to that exact code and emitting a proper error. Good starter bug.
This is actually caused by CStrings failing the task if they have an interior null. . Adding an error would fix this particular issue, but it wouldn't fix the underlying issue, so maybe a different course of action would be better. On a side note, what is the proper way to add an error to the compiler? ? ? I couldn't find any documentation on it.
What is the underlying issue? That we should always throw an error if a has an interior null character? Or that we should allow 's to have null characters?
The underlying issue was that the checked versions of tocstring and withcstr crash on interior nulls. Doing an extra interior null check before calling them in this case doesn't help with this problem in other cases, and failing the task seems unnecessary, especially for the checked version. Perhaps the checked version could return an Option, and the unchecked would keep its current behavior. Edit: Alternately, a tocstropt function could be and used where necessary.
Is anyone working on this? I'll take a crack at it this week if not.
I am. I a withcstr_opt function (that had to wait on ), and am putting the finishing touches on the error messages.
Change:
} } <ins> /// Get the [LLVM type][Type] of a [`Value`]. </ins> pub fn val_ty(v: &Value) -> &Type { unsafe { llvm::LLVMTypeOf(v) } }

Discussion:
The reference functions named and , but those functions anywhere in rustc. It seems the docs for this module have , so perhaps that is why?
modify labels to T-doc C-enhancement
It looks like has the .
modify labels: A-codegen
I finally have enough knowledge to fix these!
Change:
let field_ty = self.tcx.type_of(self.tcx.hir().local_def_id_from_hir_id(field.hir_id)); let field_ty = self.normalize_associated_types_in(field.span, &field_ty); <ins> let field_ty = self.resolve_vars_if_possible(&field_ty); debug!("non_enum_variant: type of field {:?} is {:?}", field, field_ty); </ins> AdtField { ty: field_ty, span: field.span } }) .collect();

Discussion:
Given the following source code in both and , I encounter an internal compiler error using nalgebra 0.18.0. The code is probably not legal to begin with as I ran into it as I was moving from my own homebrewn math code to nalgebra. I have the impression that the compiler probably shouldn't ICE regardless of what junk you feed it, so I'm still reporting this. Build output from : I unfortunately do not have a newer nightly to test with due to the lack of a more recent RLS blocking the rustup attempt.
Still encountering this in . Indepent of the issue, you can install specific compiler versions with necessary components and .
This ICE itself arises from this line:
triage: P-high, assigning to self. Removing nomination.
Okay I've narrowed the test case down <details<summaryclick for first reduction</summaryHere is a standalone file (): </detailsUpdate: Got a better reduction now ():
This is a stable-to-stable regression, injected between rust 1.23 and 1.24.
the fact that the bug goes away if you take away the on leads me to hypothesize that the bug is caused by some internal layout code for checking the validity (or just computing the effects) of that use of )
(Also, bisection on my mac has shown this was injected by PR )
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::{TokenStream, Ident, Span}; #[proc_macro] pub fn panic_in_libproc_macro(_: TokenStream) -> TokenStream { Ident::new("", Span::call_site()); TokenStream::new() } </ins>

Discussion:
Between nightly-2020-08-29 and nightly-2020-09-02, the following began printing an ICE message (despite compiling successfully). The relevant compiler commit range is appears extremely relevant so mentioning From the PR description it sounds like the PR was intended to have no effect unless the new -Z flag is passed. Is it possible it could be causing this? Before: After:
It looks like I misunderstood how works. I'll PR a fix tomorrow.
Assigning as and removing .
PR is up at
Change:
let mut default = DefaultCallbacks; let callbacks: &mut (dyn rustc_driver::Callbacks + Send) = if clippy_enabled { &mut clippy } else { &mut default }; <del> rustc_driver::run_compiler(&args, callbacks, None, None, None) </del> <ins> rustc_driver::RunCompiler::new(&args, callbacks).run() </ins> })) }

Discussion:
This argument list is slowly getting out of hand. Maybe we should create a builder pattern struct that doesn't require most calls to use ? Anyway, pre-existing, if you rather open an issue about it than fix it here, I'm fine with merging this PR Originally posted by in
modify labels: +A-driver +C-cleanup +T-compiler
I would like to give this a try if mentoring is available
I'll be happy to mentor, but we should wait for to get merged, because any change you do will conflict with that PR. Though you can start by basing your change on top of that PR. You will need to modify each place that is modified in that PR, so keep it bookmarked and look at it whenever you end up wondering what you may need to touch. The root change to do is to make private and add a new struct right next to it. That new struct should have a field for every parameter of the function and an inherent method () that just forwards all these fields to . You'll need a method that takes only the non- fields as parameters and creates a new instance of your builder struct with those fileds initialized and the rest set to . Then you'll need a method for each field to be able to set it. After adjusting all the callsites and everything compiles again, you should make a commit and put all follow-up changes in separate commits. As a follow up change you can make take the struct as an argument instead of all the fields individually. You can then destructure the struct in the body of to get all the fields out. There may be other things that you may notice while implementing this change that could be optimized, idk, but we can close this issue after the above changes.
Hi I was trying to get my hands on this. But since Optional fields can't be copied to runcompile, how can I pass those fields to ?. Here is code change that you suggested. I could technically replace to accept references instead of values but that will require the entire function to refactor, and I am not sure I can do that. Am I doing it wrong? What alternative I can take to get this issue fixed?
can take instead of .
Thanks just been away from rust for like 15 days and completely forgot I can do that. one more thing. was also used in miri and rls submodules.

Do I need to make a pull request there for the changes. Thanks.
Once (beta branching) is merged it is fine for miri and rls to break. Submitting a PR there is nice, but not necessary. The respective maintainers are normally the ones to fix them again.
Change:
} // Produce final compile outputs. <ins> let copy_gracefully = |from: &Path, to: &Path| { if let Err(e) = fs::copy(from, to) { sess.err(&format!("could not copy {:?} to {:?}: {}", from, to, e)); } }; </ins> let copy_if_one_unit = |ext: &str, output_type: config::OutputType, keep_numbered: bool| { // Three cases: if sess.opts.cg.codegen_units == 1 { // 1) Only one codegen unit.  In this case it's no difficulty //    to copy `foo.0.x` to `foo.x`. <del> fs::copy(&crate_output.with_extension(ext), &crate_output.path(output_type)).unwrap(); </del> <ins> copy_gracefully(&crate_output.with_extension(ext), &crate_output.path(output_type)); </ins> if !sess.opts.cg.save_temps && !keep_numbered { // The user just wants `foo.x`, not `foo.0.x`. remove(sess, &crate_output.with_extension(ext));

Discussion:
I have no idea why this is happening.
Try . And can you provide a copy of ?
You already have a file which belongs to user . Since you’re compiling as a regular user now, can’t overwrite the file and therefore fails. You can circumvent the issue by removing the file manually as root (). I’ll try to get rid of the ICE in the mean time. EDIT: this is backtrace:
Thanks, that worked.
Change:
if !visited.insert(did) { continue; } <del> for scope in &tcx.instance_mir(instance.def).source_scopes { if let Some((ref inlined, _)) = scope.inlined { result.insert(inlined.def_id()); </del> <ins> let body = tcx.instance_mir(instance.def); for block in body.basic_blocks() { for statement in &block.statements { let mir::StatementKind::Coverage(_) = statement.kind else { continue }; let scope = statement.source_info.scope; if let Some(inlined) = scope.inlined_instance(&body.source_scopes) { result.insert(inlined.def_id()); } </ins> } } }

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // xfail-test </del> pub fn main() { <del> // This is ok </del> match &[(~5,~7)] { ps => { let (ref y, _) = ps[0]; <del> println!("1. y = {}", **y); </del> assert!(**y == 5); } } <del> // This is not entirely ok </del> match Some(&[(~5,)]) { Some(ps) => { let (ref y,) = ps[0]; <del> println!("2. y = {}", **y); if **y != 5 { println!("sadness"); } </del> <ins> assert!(**y == 5); </ins> } None => () } <del> // This is not ok </del> match Some(&[(~5,~7)]) { Some(ps) => { let (ref y, ref z) = ps[0]; <del> println!("3. y = {} z = {}", **y, **z); </del> assert!(**y == 5); <ins> assert!(**z == 7); </ins> } None => () } }

Discussion:
The output: In the second , the first print statement prints out the right answer, but reading for the second time yields garbage (perhaps is wrongly getting moved out of here even though it's a ref binding?). The third just prints out garbage.
there must have been some heroic test-case minimization behind the scenes of this issue
Indeed, at first I thought the problem was process spawning... it's actually the arguments to process spawning that go wrong, even before any process gets spawned!
I thought this might be related to , but it's not; the test still fails when compiling from a branch that includes the fix for .
Modernized testcase: New output:
This appears to have been fixed, flagging as needstest.