jiebi/CodeConvo huggingface dataset:
Change:
collector.if_(); collector.assert_sorted(); <ins> println!("-- and chain --"); let collector = DropOrderCollector::default(); collector.and_chain(); collector.assert_sorted(); println!("-- or chain --"); let collector = DropOrderCollector::default(); collector.or_chain(); collector.assert_sorted(); println!("-- mixed and/or chain --"); let collector = DropOrderCollector::default(); collector.mixed_and_or_chain(); collector.assert_sorted(); </ins> println!("-- if let --"); let collector = DropOrderCollector::default(); collector.if_let();

Discussion:
If you consider the following program: It will print "2,3,4,1," four times. The issue occurs on recent nightly as well as all the way back to 1.0.0. This is a bit weird IMO, and makes && and chains non-associative. IMO it's a bug that should be fixed to print "1,2,3,4,". IDK how much we can do about this at the current point, given backwards compatibility concerns. It might not stop programs from compiling, but programs might differ in their runtime output. There is with the name "Stabilize drop order" but if you read the text, it only concerns the drop order of structs, vecs, tuples, etc. Also, after the merge, the RFC author themself made a PR to add regression tests in , and mentioned that that PR was enough for getting the RFC tested. The RFC didn't include anything about && chains. I think the language should not be interpreted too generally. It took a long time until in which we we got some further drop order tests for "established" language constructs, while there have been many PRs with drop order tests for let-else. Originally I've discovered this in: , but given that it's so visible, I'm sure that someone else has already complained about this. Maybe one can just implement the change to "1,2,3,4," and make a crater run for it? cc label T-lang
Change:
self.cx.current_expansion.is_trailing_mac = false; res } <del> _ => assign_id!(self, &mut node.id, || noop_flat_map_stmt(node, self)), </del> <ins> _ => noop_flat_map_stmt(node, self), </ins> }; }

Discussion:
ICE encountered in a , will post more details when i trace it further:
I am able to reproduce the issue with this code and : And it's combination of ("introduce" the ICE, preexisting issue) and (trigger the lint which trigger the ICE).
Further reduced to:
Change:
layout.align, None, )?; <del> if tcx.is_static(cid.instance.def_id()).is_some() { </del> <ins> if is_static { </ins> tcx.interpret_interner.cache(cid.instance.def_id(), ptr.alloc_id); } let internally_mutable = !layout.ty.is_freeze(tcx, param_env, mir.span);

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
// will be manipulated on each of the methods called on this watcher. // Wrappers should ensure to always reset the field to an appropriate value // if they rely on the field to perform an action. <del> pub fn new(stream: *mut uvll::uv_stream_t) -> StreamWatcher { unsafe { uvll::set_data_for_uv_handle(stream, 0 as *mut int) } </del> <ins> pub fn new(stream: *mut uvll::uv_stream_t, init: bool) -> StreamWatcher { if init { unsafe { uvll::set_data_for_uv_handle(stream, 0 as *mut int) } } </ins> StreamWatcher { handle: stream, last_write_req: None,

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
} } <del> // This visitor is used to mark the implemented methods of a trait. Since we // can not be sure if such methods are live or dead, we simply mark them // as live. struct TraitMethodSeeder { </del> <ins> fn has_allow_dead_code_or_lang_attr(attrs: &[ast::Attribute]) -> bool { contains_lint(attrs, allow, DEAD_CODE_LINT_STR) || attr::contains_name(attrs, "lang") } // This visitor seeds items that //   1) We want to explicitly consider as live: //     * Item annotated with #[allow(dead_code)] //         - This is done so that if we want to suppress warnings for a //           group of dead functions, we only have to annotate the "root". //           For example, if both `f` and `g` are dead and `f` calls `g`, //           then annotating `f` with `#[allow(dead_code)]` will suppress //           warning for both `f` and `g`. //     * Item annotated with #[lang=".."] //         - This is because lang items are always callable from elsewhere. //   or //   2) We are not sure to be live or not //     * Implementation of a trait method struct LifeSeeder { </ins> worklist: ~[ast::NodeId], } <del> impl Visitor<()> for TraitMethodSeeder { </del> <ins> impl Visitor<()> for LifeSeeder { </ins> fn visit_item(&mut self, item: &ast::Item, _: ()) { <ins> if has_allow_dead_code_or_lang_attr(item.attrs) { self.worklist.push(item.id); } </ins> match item.node { ast::ItemImpl(_, Some(ref _trait_ref), _, ref methods) => { for method in methods.iter() { self.worklist.push(method.id); } } <del> ast::ItemMod(..) | ast::ItemFn(..) => { visit::walk_item(self, item, ()); </del> <ins> _ => () } visit::walk_item(self, item, ()); } fn visit_fn(&mut self, fk: &visit::FnKind, _: &ast::FnDecl, block: &ast::Block, _: codemap::Span, id: ast::NodeId, _: ()) { // Check for method here because methods are not ast::Item match *fk { visit::FkMethod(_, _, method) => { if has_allow_dead_code_or_lang_attr(method.attrs) { self.worklist.push(id); } </ins> } _ => () } <ins> visit::walk_block(self, block, ()); </ins> } }

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
* @param {Row} row * @param {QueryElement} elem          - The element from the parsed query. * @param {[FunctionType]} whereClause - Trait bounds for generic items. <ins> * @param {Map<number,number>|null} mgens - Map functions generics to query generics. </ins> * * @return {boolean} - Returns true if the type matches, false otherwise. */ <del> function checkType(row, elem, whereClause) { </del> <ins> function checkType(row, elem, whereClause, mgens) { </ins> if (row.bindings.size === 0 && elem.bindings.size === 0) { if (elem.id < 0) { <del> return row.id < 0 || checkIfInList(row.generics, elem, whereClause); </del> <ins> return row.id < 0 || checkIfInList(row.generics, elem, whereClause, mgens); </ins> } if (row.id > 0 && elem.id > 0 && elem.pathWithoutLast.length === 0 && typePassesFilter(elem.typeFilter, row.ty) && elem.generics.length === 0 && // special case elem.id !== typeNameIdOfArrayOrSlice ) { <del> return row.id === elem.id || checkIfInList(row.generics, elem, whereClause); </del> <ins> return row.id === elem.id || checkIfInList( row.generics, elem, whereClause, mgens ); </ins> } } <del> return unifyFunctionTypes([row], [elem], whereClause); </del> <ins> return unifyFunctionTypes([row], [elem], whereClause, mgens); </ins> } function checkPath(contains, ty, maxEditDistance) {

Discussion:
sqlx was updated yesterday. and its search is now broken. compare: with:
Firefox prints those errors: with label -needs-triage +T-rustdoc +A-rustdoc-search +regression-untriaged cc
Change:
match *self { LintSource::Default => DUMMY_SP, LintSource::Node(_, span, _) => span, <del> LintSource::CommandLine(_) => DUMMY_SP, </del> <ins> LintSource::CommandLine(_, _) => DUMMY_SP, </ins> } } }

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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
let kind_place = kind.filter(|_| place_desc.is_some()).map(|k| (k, place_span.0)); let explanation = self.explain_why_borrow_contains_point(location, &borrow, kind_place); <ins> debug!( "report_borrowed_value_does_not_live_long_enough(place_desc: {:?}, explanation: {:?})", place_desc, explanation ); </ins> let err = match (place_desc, explanation) { (Some(_), _) if self.is_place_thread_local(root_place) => { self.report_thread_local_value_does_not_live_long_enough(drop_span, borrow_span)

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
R: RangeBounds<K>, { let (start, end) = self.range_slice_indices(range); <del> (&self.data[start..end]) </del> <ins> &self.data[start..end] </ins> } #[inline]

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
pub fn coroutine_witness_ty(self) -> Ty<'tcx> { self.split().coroutine_witness_ty } <ins> pub fn has_self_borrows(&self) -> bool { match self.coroutine_captures_by_ref_ty().kind() { ty::FnPtr(sig) => sig .skip_binder() .visit_with(&mut HasRegionsBoundAt { binder: ty::INNERMOST }) .is_break(), ty::Error(_) => true, _ => bug!(), } } } /// Unlike `has_escaping_bound_vars` or `outermost_exclusive_binder`, this will /// detect only regions bound *at* the debruijn index. struct HasRegionsBoundAt { binder: ty::DebruijnIndex, } // FIXME: Could be optimized to not walk into components with no escaping bound vars. impl<'tcx> TypeVisitor<TyCtxt<'tcx>> for HasRegionsBoundAt { type Result = ControlFlow<()>; fn visit_binder<T: TypeVisitable<TyCtxt<'tcx>>>( &mut self, t: &ty::Binder<'tcx, T>, ) -> Self::Result { self.binder.shift_in(1); t.super_visit_with(self)?; self.binder.shift_out(1); ControlFlow::Continue(()) } fn visit_region(&mut self, r: ty::Region<'tcx>) -> Self::Result { if let ty::ReBound(binder, _) = *r && self.binder == binder { ControlFlow::Break(()) } else { ControlFlow::Continue(()) } } </ins> } #[derive(Copy, Clone, PartialEq, Eq, Debug, TypeFoldable, TypeVisitable)]

Discussion:
I've returned to one of my projects after a few months of pause. Before I was using rust nigthly ~1.7x (around November 2023). It also worked through whole 2022 and 2021 IIRC. I've moved to new computer and installed rust nightly 1.80 (latest). After upgrading I noticed that my whole codebase is full of errors around capturing something from environment. . However if I change to it builds and works like previosly. Minimal example below. The error for first method is: i booted my very old PC to check, this is definately not the last version this worked fine: I definately does not work with:
Minimal: This should be possible now to support due to changes in . I'll put up a fix soon.
Change:
<ins> fn main() { let x = Some(123); if let Some(y) = x else { //~ ERROR this `if` expression is missing a block return; }; } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest removing the additional keyword in front of the . This mistake can occur due to muscle memory as , , and in the future are somewhat similar syntactically. Thanks. label +D-confusing +F-let-else <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the current suggestion is valid. Because one writes instead of writing . So the suggestion if changed maybe fall-negative.
We should likely add an alternative suggestion to remove the , but keep both. I think that the current suggestion is likely going to be the more common situation, so it should still come first.
claim
What would be the best way to go about adding an alternate suggestion? I'd like to try my hand at this. What I think needs to be done is adding help text to , add a variant to , and then add something to to add the alternate after the primary suggestion. Is this a good starting point?
it sounds like you are in the right path.
I looked a bit into this issue and have already found where to add text to the and the as mentioned, but i am a bit overwhelmed how and where to start in the in the . Does anyone have a hint for me?
claim
claim
You can add instructions in the parser to track your progress.

I'm not sure about the specifics out of the top of my head here of what type each step in the parse is, but you will have successfully parsed the , the condition and then you'll encounter an token when a body/block was expected. That's where the new recovery should kick in, pointing at the span saying that you might want to remove it.
claim
Change:
<del> //@ known-bug: #117829 auto trait Z<'a, T: ?Sized> where T: Z<'a, u16>, for<'b> <T as Z<'b, u16>>::W: Clone, { type W: ?Sized; } </del>

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. --<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16', 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16' File: --auto-reduced (treereduce-rust): original: 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
Regression in nightly-2023-06-18 Regression in / ping
The depth of the stack at the ICE depends on the recursion limit. Add and it still ICEs, but with only 8 repeated stack portions.
Simplified to use only locally defined traits, not use a lifetime parameter, and hit fewer errors: Oddly enough, this variant hits the same ICE but without such a deep stack.
You can replace the bound with a lifetime bound to reproduce too, such as .
Change:
-> Option<UnsizeKind<'tcx>> { match t.sty { ty::TySlice(_) | ty::TyStr => Some(UnsizeKind::Length), <del> ty::TyTrait(_) => Some(UnsizeKind::Vtable), </del> <ins> ty::TyTrait(ref tty) => Some(UnsizeKind::Vtable(tty.principal_def_id())), </ins> ty::TyStruct(did, substs) => { match ty::struct_fields(fcx.tcx(), did, substs).pop() { None => None,

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
|     | |     required by a bound introduced by this call | <del> = note: consider using `Box::pin` </del> <ins> = note: consider using the `pin!` macro consider using `Box::pin` if you need to access the pinned value outside of the current scope </ins> note: required by a bound in `copy` --> $DIR/issue-90164.rs:1:12 |

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
} } PatKind::Path(ref qpath) => { <del> let (def, _, _) = self.resolve_ty_and_res_ufcs(qpath, pat.hir_id, pat.span); match def { </del> <ins> let resolution = self.resolve_ty_and_res_ufcs(qpath, pat.hir_id, pat.span); path_resolution = Some(resolution); match resolution.0 { </ins> Res::Def(DefKind::Const, _) | Res::Def(DefKind::AssocConst, _) => false, _ => true, }

Discussion:
The following, which I expect to work, fails to infer the type of : In HIR, should correspond to: However, if we change the snippet to: it all works out fine. I also tested changing to a tuple variant and that works also. cc cc
It might be a good idea to trace the difference between and because they look relatively similar and yet they behave differently in terms of inference.
Value (/) and type () namespaces execute very different logic for type inference (/ vs ). It's quite possible that there are intended and unintended observable differences (not necessarily specific to ). checkpatpath and checkpattuplestruct Rather and . ( is the same "value" case as .)