jiebi/CodeConvo huggingface dataset:
Code change:
trait_ref: ty::TraitRef<'tcx>, impl_def_id: LocalDefId, ) { <del> assert_eq!(trait_ref.args.len(), 1); </del> <ins> if trait_ref.args.len() != 1 { tcx.sess.diagnostic().delay_span_bug( tcx.def_span(impl_def_id), "auto traits cannot have generic parameters", ); return; } </ins> let self_ty = trait_ref.self_ty(); let (self_type_did, args) = match self_ty.kind() { ty::Adt(def, args) => (def.did(), args),

Related discussion:
text: <!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2022-02-02 found 9 bors merge commits in the specified range commit[0] 2022-01-31: Auto merge of - spastorino:fix-perf-overlap-mode2, r=nikomatsakis commit[1] 2022-01-31: Auto merge of - tmiasko:is-self-recursive, r=ecstatic-morse commit[2] 2022-02-01: Auto merge of - WaffleLapkin:rustcmustimplementoneofchecktarget, r=nagisa commit[3] 2022-02-01: Auto merge of - eddyb:diagbld-scalar-pair, r=jackh726 commit[4] 2022-02-01: Auto merge of - ehuss:rollup-9ecozo9, r=ehuss commit[5] 2022-02-01: Auto merge of - thomcc:chunky-splitz-says-no-checking, r=the8472 commit[6] 2022-02-01: Auto merge of - eholk:disable-drop-range-analysis, r=pnkfelix commit[7] 2022-02-01: Auto merge of - matthiaskrgr:rollup-f7dkn3p, r=matthiaskrgr commit[8] 2022-02-01: Auto merge of - yaahc:Termination-abstraction, r=Mark-Simulacrum ERROR: no CI builds available between and within last 167 days
Actually reduced
Might have been caused by
Ah yes, the assert was there ping :)
Code change:
<del> // no-prefer-dynamic </del> // This would previously leak the Box<Trait> because we wouldn't // schedule cleanups when auto borrowing trait objects. // This program should be valgrind clean.

Related discussion:
text: Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?
Code change:
break; case "+": <ins> ev.preventDefault(); expandAllDocs(); break; </ins> case "-": ev.preventDefault(); <del> toggleAllDocs(); </del> <ins> collapseAllDocs(); </ins> break; case "?":

Related discussion:
text: Take any page in the Rust docs, for example . When you press the or keyboard shortcuts on your keyboard, they are supposed to either collapse or expand all items on the page, but not both (according to the instructions that you can find by clicking on your keyboard (or on the screen). Please make the + and - keyboard shortcuts idempotent, otherwise it would be redundant to have two buttons that do the same thing.
What do you think about this ?
Yeah we should do this.
I'll send a patch in the next days then.
Code change:
<ins> // edition:2021 use std::iter; fn f<T>(data: &[T]) -> impl Iterator<Item = Vec> { //~^ ERROR: missing generics for struct `Vec` [E0107] iter::empty() //~ ERROR: type annotations needed [E0282] } fn g<T>(data: &[T], target: T) -> impl Iterator<Item = Vec<T>> { //~^ ERROR: type annotations needed [E0282] f(data).filter(|x| x == target) } fn main() {} </ins>

Related discussion:
text: Repro steps: create a new cargo binary with . Replace with the following code. Then run . Hope this is helpful! I've tried to minimize the code as much as possible. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The same issue happens in the latest nightly as well.
This bisects to nightly-2021-06-25. Commit range: It only reproduces with , not , which means bisecting to the old nightly needs in In that range, looks the most relevant because it is the only thing introducing edition-specific behavior, and it's dealing with closure capture and the presence of a closure appears necessary in the minimal repro. would you be interested in taking a look?
For comparison, the same code with doesn't emit a compiler error and has a bit more info:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
In both and , function returns value every time but somehow in value unwraps into error, even though it's This is the returned value:
Triage: This is no longer ICE with the latest nightly, since (presumably ). Marked as .
Code change:
# These arguments get passed through to GDB and make it load the # Rust pretty printers. <del> GDB_ARGS="--directory="$GDB_PYTHON_MODULE_DIRECTORY" -iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY"" </del> <ins> GDB_ARGS="--directory="$GDB_PYTHON_MODULE_DIRECTORY""  "-iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY""  "-iex "set substitute-path /rustc/$RUSTC_COMMIT_HASH $RUSTC_SYSROOT/lib/rustlib/src/rust"" </ins> # Finally we execute gdbgui. PYTHONPATH="$PYTHONPATH:$GDB_PYTHON_MODULE_DIRECTORY" 

Related discussion:
text: I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.
Code change:
pub type PolyTraitPredicate<'tcx> = ty::Binder<'tcx, TraitPredicate<'tcx>>; impl<'tcx> TraitPredicate<'tcx> { <ins> pub fn remap_constness(&mut self, tcx: TyCtxt<'tcx>, param_env: &mut ParamEnv<'tcx>) { if unlikely!(Some(self.trait_ref.def_id) == tcx.lang_items().drop_trait()) { // remap without changing constness of this predicate. // this is because `T: ~const Drop` has a different meaning to `T: Drop` param_env.remap_constness_with(self.constness) } else { *param_env = param_env.with_constness(self.constness.and(param_env.constness())) } } </ins> pub fn def_id(self) -> DefId { self.trait_ref.def_id }

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: print (from Debug impl) Instead, this happened: E0277, trait impl not found This was found by CI in the Ruffle Project: The issue is caused by the effective anti-bound of Drop, introduced by the manual impl of the trait, as well as the PR which introduced bounds for a number of functions in . It most recently worked on: rustc 1.59.0-nightly ( 2021-12-18) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
Code change:
until the stack is unwound and the task transitions to the *dead* state. There is no way to "recover" from task failure.  Once a task has temporarily suspended its unwinding in the *failing* state, failure <del> occurring from within this destructor results in *hard* failure.  The unwinding procedure of hard failure frees resources but does not execute destructors.  The original (soft) failure is still resumed at the point where it was temporarily suspended. </del> <ins> occurring from within this destructor results in *hard* failure. A hard failure currently results in the process aborting. </ins> A task in the *dead* state cannot transition to other states; it exists only to have its termination status inspected by other tasks, and/or to await

Related discussion:
text: Currently there are no landing pads generated for resource destructors so they are leaky when they fail. We don't have the same tricky situation that C++ has with throwing destructors but I haven't thought through how it should work yet. Edit: This issue has changed into what to do after a dtor fails during unwinding. The previous issue of dtor failure not working at all has been resolved.
There's a failing test in run-fail/unwind-resource-
And another in run-fail/unwind-resource-
The language reference is actually quite explicit about this: "A task may transition to the failing state at any time, due to an un-trapped signal or the evaluation of a fail expression. Once failing, a task unwinds its stack and transitions to the dead state. Unwinding the stack of a task is done by the task itself, on its own control stack. If a value with a destructor is freed during unwinding, the code for the destructor is run, also on the task's control stack. Running the destructor code causes a temporary transition to a running state, and allows the destructor code to cause any subsequent state transitions. The original task of unwinding and failing thereby may suspend temporarily, and may involve (recursive) unwinding of the stack of a failed destructor. Nonetheless, the outermost unwinding activity will continue until the stack is unwound and the task transitions to the dead state. There is no way to “recover” from task failure. Once a task has temporarily suspended its unwinding in the failing state, failure occurring from within this destructor results in hard failure. The unwinding procedure of hard failure frees resources but does not execute destructors. The original (soft) failure is still resumed at the point where it was temporarily suspended. "
Yeah. The hard/soft thing has never been implemented, as far as I know, but I think it's the best we can do: retain correctness of our memory model and try to retain correctness of user code, but not at the cost of infinite-recursion. If their dtor itself fails, just unwind that sub-failure w/o the opportunity for sub-sub-failures.
It would be good to revise the title of this bug to reflect what the task is.
Code change:
until the stack is unwound and the task transitions to the *dead* state. There is no way to "recover" from task failure.  Once a task has temporarily suspended its unwinding in the *failing* state, failure <del> occurring from within this destructor results in *hard* failure.  The unwinding procedure of hard failure frees resources but does not execute destructors.  The original (soft) failure is still resumed at the point where it was temporarily suspended. </del> <ins> occurring from within this destructor results in *hard* failure. A hard failure currently results in the process aborting. </ins> A task in the *dead* state cannot transition to other states; it exists only to have its termination status inspected by other tasks, and/or to await

Related discussion:
text: (From the comments thus far, it sounds like the task is to implement the hard/sort failure unwindin protocol; but it might also be useful to clean up the docs here.)
Not critical for 0.6; de-milestoning
confirmed again; current code that can crash is as follows: If my idea for an effect system goes through, we might make this sound again by simply requiring no failure in destructors, e.g. .
nominating for well-defined milestone
there is language about this in the manual already in the task section, so I think it's well defined already. just not implemented. feature completeness issue.
accepted for feature-complete milestone
Triage: the updated version of example still crashes:
0 backcompat
This not only applies to destructors failing while failing, but this appears to also apply to linked failure as well. A program may only contain one statement, but it may still leak due to linked failure. An example of this would be: The destructor for never runs in this program because the call to invokes scheduler business which will realize that it needs to fail due to linked failure. It seems odd to me that if a task only contains one source of failure then we can still leak. This specific use case may not entirely fall under this issue, but it seems fairly serious.
The scheduler does have logic for not failing from linked failure when a task is already failing. So if, for example, the sleeping destructor here were to happen during unwinding, I think it should be fine. But if it happens normally you could still get failure.
I've updated the title to reflect what we're currently talking about. My understanding is that it is just impossible to throw from a landing pad because it will potentially corrupt the unwinder and our three options are: abort - this is what C++ does resume unwinding without completing the landing pad - this is what Ada does and we haven't discussed this option abort the task without completing unwinding - this is "hard" failure we've talked about The "hard" failure is made more difficult by tasks that are not simply green threads. For example, we have use cases where we want to run in a 'task context', on the current thread, and then be told whether the task succeeded or failed, all on the same thread. There's no way in that scenario to just terminate the task cleanly.
Code change:
until the stack is unwound and the task transitions to the *dead* state. There is no way to "recover" from task failure.  Once a task has temporarily suspended its unwinding in the *failing* state, failure <del> occurring from within this destructor results in *hard* failure.  The unwinding procedure of hard failure frees resources but does not execute destructors.  The original (soft) failure is still resumed at the point where it was temporarily suspended. </del> <ins> occurring from within this destructor results in *hard* failure. A hard failure currently results in the process aborting. </ins> A task in the *dead* state cannot transition to other states; it exists only to have its termination status inspected by other tasks, and/or to await

Related discussion:
text: My current opinion is that, for 1.0 we should take the most conservative approach and abort. For future versions we should consider trying to do what Ada does and skip a single landing pad, but still proceed to catch the exception.
I agree with double-abort for 1.0. Thinking about the other two schemes in terms of how RWARCs (or whatever they're called these days) behave, aborting just a single task strikes me as risky in terms of unexpected behaviour befalling the user. If a double-failure occurs inside an access to a RWARC, it won't be automatically unlocked during unwinding, and other contending tasks will block forever. I think that resuming the unwinding and skipping the one landing pad still makes sense, though. If double-failure occurs in a user-provided destructor (or in the destructor of some buggy library), skipping the rest of the destructor can only "surprise" other code directly associated with the faulty destructor.
I agree too.
Code change:
/// all files in a directory and updating the stamp if any are newer. fn update_mtime(path: &Path) { let mut max = None; <del> if let Ok(entries) = path.parent().unwrap().read_dir() { </del> <ins> if let Ok(entries) = path.parent().unwrap().join("deps").read_dir() { </ins> for entry in entries.map(|e| t!(e)) { if t!(entry.file_type()).is_file() { let meta = t!(entry.metadata());

Related discussion:
text: These two errors, which I believe are related, have started happening with rustbuild recently. I think the second is sometimes caused by the first after trying to avoid cleaning out everything; but since this is all nondeterministic from what I can tell I've included it in case it helps diagnose the problem. cc
A few more lines of potentially helpful information:
Code change:
/// all files in a directory and updating the stamp if any are newer. fn update_mtime(path: &Path) { let mut max = None; <del> if let Ok(entries) = path.parent().unwrap().read_dir() { </del> <ins> if let Ok(entries) = path.parent().unwrap().join("deps").read_dir() { </ins> for entry in entries.map(|e| t!(e)) { if t!(entry.file_type()).is_file() { let meta = t!(entry.metadata());

Related discussion:
text: Before the recent changes to rustbuild, when changing , it has rebuilt the entire stage0 artifacts and thus the entire compiler. Now its only doing: Later on, you are getting an error like "found possibly newer version of crate which depends on".
cc note, I'm not using any --keep-stage stuff or anything.
workaround is to do manually
I think this is the same as (or that's the same as this), haven't had a chance to investigate yet. My guess is that this is a regression from
yes I think its the same issue. If you are closing dupes, then please close the one that was filed later :)
Code change:
req_name: ReqName, ret_allow_plus: AllowPlus, ) -> PResult<'a, P<FnDecl>> { <del> let inputs = self.parse_fn_params(req_name)?; let output = self.parse_ret_ty(ret_allow_plus, RecoverQPath::Yes)?; if let ast::FnRetTy::Ty(ty) = &output { if let TyKind::Path(_, Path { segments, .. }) = &ty.kind { if let [.., last] = &segments[..] { // Detect and recover `fn foo() -> Vec<i32>> {}` self.check_trailing_angle_brackets(last, &[&token::OpenDelim(token::Brace)]); } } } Ok(P(FnDecl { inputs, output })) </del> <ins> Ok(P(FnDecl { inputs: self.parse_fn_params(req_name)?, output: self.parse_ret_ty(ret_allow_plus, RecoverQPath::Yes)?, })) </ins> } /// Parses the parameter list of a function, including the `(` and `)` delimiters.

Related discussion:
text: Alternate title: "Rust is literally C++" As of nightly-2020-10-29, rustc fails to parse the following code. The previous nightly and all past stable releases since 1.0.0 are not affected. The relevant commit range is
Mentioning because "Tweak invalid  header and body parsing" sounds extremely relevant.
Assigning and removing as in the prioritization working group.
searched nightlies: from nightly-2020-10-27 to nightly-2020-10-29 regressed nightly: nightly-2020-10-29 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsYeah, seems likely that is the culprit.
Yep, this was me :-/ I'll have a PR up in the next hour.
Code change:
children.iter() .map(|sub| self.get_multispan_max_line_num(&sub.span)) .max() <del> .unwrap_or(primary) </del> <ins> .unwrap_or(0) .max(primary) </ins> } /// Adds a left margin to every line but the first, given a padding length and the label being

Related discussion:
text: This is the correct output. Notice that one of the errors has a column of whitespace between the line number and the pipes, the next does not. Commit range:
Mentioning who made changes in librustc_errors. Could this be from ?
It looks like this can cause the wrong line number to be printed. :( If you bump the problematic line down to line 100, it prints as 10:
It seems like it might be.
Indeed. Upon closer inspection I've found out that actually changes the semantics of method: after applying this commit, if is not empty, then of them is not compared with , although could actually be greater. The correct code should rather look like this: Although it might be not the bug responsible for this issue, it definetely should be fixed. I'll make a PR with fix ASAP. EDIT:
Subtle. That seems about right.
Code change:
<ins> fn main() { [(); &(&'static: loop { |x| {}; }) as *const _ as usize] //~^ ERROR: invalid label name `'static` //~| ERROR: type annotations needed } </ins>

Related discussion:
text: Binder(<[type error] as ToBytes) This only happens if there are two erroneous functions, if I take out it works fine. It seems like I was trying to do this wrong in the first place since the first function gives an error . Not sure what the right way to do this is. <details<summaryTraceback</summary</details
Tried to reduce it and found a similar case with the same ICE:
Compiler triage: Seems likely to be caused by the need for lazy norm. Marking as p-medium for now.
The ICE doesn't appear on the latest nightly, marked as E-needstest
Code change:
trait_id: DefId, ty_params: &[GenericArg<'tcx>], ) -> bool { <ins> // Do not check on infer_types to avoid panic in evaluate_obligation. if ty.has_infer_types() { return false; } let ty = cx.tcx.erase_regions(&ty); </ins> let ty_params = cx.tcx.mk_substs(ty_params.iter()); cx.tcx.type_implements_trait((trait_id, ty, ty_params, cx.param_env)) }

Related discussion:
text: <!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc
Code change:
LL |     println!("hello world"); |              ~           ~ <del> error: aborting due to 1 previous error </del> <ins> error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0762`.

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
:thinking: this bisects to cc
very plausible :+1:
Reduced
Code change:
"llvm-ar", // used for creating and modifying archive files ]; <ins> pub const VERSION: usize = 2; </ins> /// A structure representing a Rust compiler. /// /// Each compiler has a `stage` that it is associated with and a `host` that

Related discussion:
text: New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.