jiebi/CodeConvo huggingface dataset:
Change:
} TyKind::BareFn(barefn) => BareFunction(Box::new(clean_bare_fn_ty(barefn, cx))), // Rustdoc handles `TyKind::Err`s by turning them into `Type::Infer`s. <del> TyKind::Infer | TyKind::Err => Infer, TyKind::Typeof(..) => panic!("unimplemented type {:?}", ty.kind), </del> <ins> TyKind::Infer | TyKind::Err | TyKind::Typeof(..) => Infer, </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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :smile:
This really should fail before rustdoc gets to it, unless rustdoc has a representation :thinking:
An (the?) interesting bit here is that it's a very recent regression, for instance does not produce an ICE:
claim
This regressed in cc
Hmm I don't know how that caused it.
Change:
let expr_ty = self.node_ty(expr.id); self.demand_suptype(expr.span, expr_ty, return_ty); <ins> } else { // We could not perform a mutable index. Re-apply the // immutable index adjustments - borrowck will detect // this as an error. if let Some(adjustment) = adjustment { self.apply_adjustment(expr.id, adjustment); } self.tcx.sess.delay_span_bug( expr.span, "convert_lvalue_derefs_to_mutable failed"); </ins> } } hir::ExprUnary(hir::UnDeref, ref base_expr) => {

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
.SH ENVIRONMENT <del> Some of these affect the output of the compiler, while others affect programs which link to the standard library. </del> <ins> Some of these affect only test harness programs (generated via rustc --test); others affect all programs which link to the Rust standard library. </ins> .TP fBRUST_TEST_THREADSfR

Discussion:
Here it is: I believe that the line here is incorrect "Some of these affect the output of the compiler, while others affect programs which link to the standard library." since I believe none of these variables affect the output of the compiler. Why is this a problem? Well, the logical reader might say to themselves: " "Some" means at least 1. It makes very little sense for the top three to affect the output of the compiler. Therefore it must be the bottom one, RUST_BACKTRACE, which affects the output of the compiler."
I think "the output" should just be removed here - applies to both rustc and binaries produced by it, for example.
First, I do agree the phrase "the output of the compiler" is suboptimal, since it can be taken to mean the diagnostics emitted to stdout or other files it generates, while the original intent here (I think) is for the word "output" to denote the behavior of the binary generated by the compiler. Second, while saying "Some of these affect the compiler, ..." would be technically correct, I think it would be misleading. In particular, I personally would read the phase " affects the compiler", at least initially, as meaning that the environment variable only matters during execution of the compiler itself, which is the opposite of what we want to convey. How about: all programs which link to the Rust standard library. (I'm actually not particularly wedded to that second sentence. I would not mind if it were omitted.)
Thanks, Now that you point it out I realize that the problem with the problematic statement is not that it is wrong, so much as that it is entirely ambiguous and that when reading it it is easy to choose the wrong, that is unintended, meaning. Your suggested wording works for me.
I think the extra note on the end is likely to make things more confusing. So keeping it to only the first part of your suggestion is the best I think!: If you want I could create a PR for this?
I'ld be fine w/ that wording as well.
I created a PR for you !
Change:
let js_dst = this.dst.join("sidebar-items.js"); let mut js_out = BufWriter::new(try_err!(File::create(&js_dst), &js_dst)); try_err!(write!(&mut js_out, "initSidebarItems({});", <del> json::as_json(&items)), &js_dst); </del> <ins> as_json(&items)), &js_dst); </ins> } for item in m.items {

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
<ins> // This is a non-regression test for issue #114325: an "unexpected unsized tail" ICE happened during // codegen, and was fixed by MIR drop tracking #107421. // edition: 2021 // build-pass: ICEd during codegen. #![feature(impl_trait_in_assoc_type)] use std::future::Future; fn main() { RuntimeRef::spawn_local(actor_fn(http_actor)); } async fn http_actor() { async fn respond(body: impl Body) { body.write_message().await; } respond(&()).await; } trait Body { type WriteFuture: Future; fn write_message(self) -> Self::WriteFuture; } impl Body for &'static () { type WriteFuture = impl Future<Output = ()>; fn write_message(self) -> Self::WriteFuture { async {} } } trait NewActor { type RuntimeAccess; } fn actor_fn<T, A>(_d: T) -> (T, A) { loop {} } impl<F: FnMut() -> A, A> NewActor for (F, A) { type RuntimeAccess = RuntimeRef; } struct RuntimeRef(Vec<()>); impl RuntimeRef { fn spawn_local<NA: NewActor<RuntimeAccess = RuntimeRef>>(_f: NA) { struct ActorFuture<NA: NewActor>(NA::RuntimeAccess); (ActorFuture::<NA>(RuntimeRef(vec![])), _f); } } </ins>

Discussion:
Sorry in advance, this is going to be a pretty poor bug report as I don't have much time to look into this at the moment, but I did want to create an issue for it. asyncfnintrait asynciterator constmutrefs constoption constweaknew docautocfg doccfghide extractif impltraitinassoctype iosliceadvance issorted maybeuninitarrayassumeinit maybeuninituninitarray maybeuninitwriteslice nevertype newuninit noopwaker ptrmetadata stmtexprattributes wakergetters I found that I can reproduce it in public code as well: Running fails, specifically this example: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimzed to: This now errors with "unexpected unsized tail: usize", but i think that should be alright (?). If someone really needs the original error, I might have it lying around somewhere.
Triage: The above minimal code now compiles successfully on 1.77.0-nightly (2023-12-24 ), so this issue may have been fixed or may need a new MCVE.
Can confirm that this has been resolved. Do we want to keep this open to add a regression test? Otherwise I'm fine with closing.
If the issue is fixed in and your private code, then let's use the MCVE above to add a regression test. label -E-needs-mcve +E-needs-test
Change:
return (true, candidates); } } <ins> // Try to find in last block rib if let Some(rib) = &self.last_block_rib && let RibKind::NormalRibKind = rib.kind { for (ident, &res) in &rib.bindings { if let Res::Local(_) = res && path.len() == 1 && ident.span.eq_ctxt(path[0].ident.span) && ident.name == path[0].ident.name { err.span_help( ident.span, &format!("the binding `{}` is available in a different scope in the same function", path_str), ); return (true, candidates); } } } </ins> return (false, candidates); }

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
while_expr(40, 41, 42); loop_expr(43, 44, 45); }

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
_6 = const 1_i32;                // scope 0 at $DIR/loop_test.rs:14:17: 14:18 FakeRead(ForLet(None), _6);      // scope 0 at $DIR/loop_test.rs:14:13: 14:14 StorageDead(_6);                 // scope 0 at $DIR/loop_test.rs:16:5: 16:6 <del> goto -> bb3;                     // scope 0 at $DIR/loop_test.rs:1:1: 1:1 </del> <ins> goto -> bb3;                     // scope 0 at no-location </ins> } bb5 (cleanup): {

Discussion:
Sysroot has been compiled using to get set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:
I used to read the mir.
I think these are and printed as . If so it would be less confusing if the debug impl of would say or something like that instead.
I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for , but without a test for that I'm not sure how to test it
Change:
/// Format trait for an empty format, `{}`. /// <ins> /// Implementing this trait for a type will automatically implement the /// [`ToString`][tostring] trait for the type, allowing the usage /// of the [`.to_string()`][tostring_function] method. Prefer implementing /// the `Display` trait for a type, rather than [`ToString`][tostring]. /// </ins> /// `Display` is similar to [`Debug`], but `Display` is for user-facing /// output, and so cannot be derived. /// /// For more information on formatters, see [the module-level documentation][module]. /// /// [module]: ../../std/fmt/index.html <ins> /// [tostring]: ../../std/string/trait.ToString.html /// [tostring_function]: ../../std/string/trait.ToString.html#tymethod.to_string </ins> /// /// # Examples ///

Discussion:
I just on URLO about when to implement or not to implement , and I noticed that the trait are lacking. In particular, I believe they should definitely point out that implementing will give a type a method via the trait. This is important to keep in mind when you’re designing an API; it’s also the reason why in the standard library doesn’t implement directly (but offers a method): because converting to is lossy or fallible, and an (implicitly) lossy method would not fit the API. label A-docs, C-enhancement, T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim Edit: Not sure if I stole this from you , on my end it looks like you were unassigned most recently.
Change:
fs::write(&path, contents).map_err(|e| E::new(e, path))?; } <del> #[cfg(not(windows))] fs::write(&path, contents).map_err(|e| E::new(e, path))?; </del> Ok(()) } } <ins> impl Drop for DocFS { fn drop(&mut self) { self.pool.join(); } } </ins>

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc
Change:
inherited.typeck_results.borrow_mut().liberated_fn_sigs_mut().insert(fn_id, fn_sig); <del> if let ty::Dynamic(..) = declared_ret_ty.kind() { </del> <ins> if let ty::Dynamic(_, _, ty::Dyn) = declared_ret_ty.kind() { </ins> // FIXME: We need to verify that the return type is `Sized` after the return expression has // been evaluated so that we have types available for all the nodes being returned, but that // requires the coerced evaluated type to be stored. Moving `check_return_expr` before this

Discussion:
() This happens whether or not the returned type implements the trait in question. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels +F-dyn_star
Change:
let llty = bx.fn_ptr_backend_type(fn_abi); let ptr_size = bx.data_layout().pointer_size; <del> let ptr_align = bx.data_layout().pointer_align.abi; </del> let vtable_byte_offset = self.0 * ptr_size.bytes(); <del> if bx.cx().sess().opts.unstable_opts.virtual_function_elimination && bx.cx().sess().lto() == Lto::Fat { let typeid = bx .typeid_metadata(typeid_for_trait_ref(bx.tcx(), expect_dyn_trait_in_self(ty))) .unwrap(); let func = bx.type_checked_load(llvtable, vtable_byte_offset, typeid); func } else { let gep = bx.inbounds_ptradd(llvtable, bx.const_usize(vtable_byte_offset)); let ptr = bx.load(llty, gep, ptr_align); // VTable loads are invariant. bx.set_invariant_load(ptr); if nonnull { bx.nonnull_metadata(ptr); } ptr } </del> <ins> load_vtable(bx, llvtable, llty, vtable_byte_offset, ty, nonnull) </ins> } pub(crate) fn get_optional_fn<Bx: BuilderMethods<'a, 'tcx>>(

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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<!-- query stack: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
// are not directly inspecting closure types // anyway, except via auto trait matching (which // only inspects the upvar types). <del> walker.skip_current_subtree(); // subtree handled by compute_projection </del> <ins> walker.skip_current_subtree(); // subtree handled below </ins> for upvar_ty in substs.as_closure().upvar_tys() { <ins> // FIXME(eddyb) add the type to `walker` instead of recursing. </ins> self.compute(upvar_ty); } }

Discussion:
returns if it can't make progress on an inference variable, and the original obligation should be retried later. However, doesn't check that return type and may (incorrectly) return no obligations. On I suggested this: I'm pretty sure now that it would've prevented this bug. <hr/Looking at the users, only uses this function, and only for the user-specified bounds, so it's possible inference variables are impossible to find (unless normalization introduces them, I guess?). It might be fine to just create obligation for the instead of bailing out (see below, this is the same as moving out of ) It's true that can't be found as the first type in the recursive call, but is a , and it uses . (EDIT: Read the code more carefully and the check is , so while it's not an early like I would prefer, it does seem to only trigger on the root type) However, a few other things call and it would be fine for them to create an obligation rather than erroring out, so maybe itself should do that check? cc
changes the return type of to a and discards it using . Might cause us to be slightly more cautious in the future.
I'm working on a fix that makes itself never bail out, so the check is done in , hopefully that will also work nicely for consts. EDIT: opened .
Change:
//! | Type               | Analogous to | //! | ------------------ | ------------ | //! | [`RawFd`]          | `*const _`   | <del> //! | [`BorrowedFd<'a>`] | `&'a _`      | //! | [`OwnedFd`]        | `Box<_>`     | </del> <ins> //! | [`BorrowedFd<'a>`] | `&'a Arc<_>` | //! | [`OwnedFd`]        | `Arc<_>`     | </ins> //! //! Like raw pointers, `RawFd` values are primitive values. And in new code, //! they should be considered unsafe to do I/O on (analogous to dereferencing

Discussion:
In std::io, : Note that exclusive ownership of a file descriptor does not imply exclusive ownership of the underlying kernel object that the file descriptor references (also called “file description” on some operating systems). File descriptors basically work like : when you receive an owned file descriptor, you cannot know whether there are any other file descriptors that reference the same kernel object. However, when you create a new kernel object, you know that you are holding the only reference to it. Just be careful not to lend it to anyone, since they can obtain a clone and then you can no longer know what the reference count is! In that sense, is like Arc and is like &'a Arc However the table in std::io::unix::io has the table saying: =Box<This is incorrect and potentially very misleading, because the result of ping a file descriptor creates a new fd which shares the same underlying file structure in the kernel. In particular, for seekable fds they share the current file offset (ie, used by and ) and in some cases, file locking state. (In addition to inode state and underlying file/pipe/etc contents.) The language here should reflect the language in std::io.
cc - I think this is something that should have addressed.
Yeah the model described in doesn't take into account and the indirection layer of "file descriptors" vs "file descriptions". (That was already the case before though, it just became a lot more apparent with that PR.)
Change:
if ty::try_add_builtin_trait(tcx, trait_did, &mut builtin_bounds) { <del> // FIXME(#20302) -- we should check for things like Copy<T> </del> <ins> let segments = &b.trait_ref.path.segments; let parameters = &segments[segments.len() - 1].parameters; if parameters.types().len() > 0 { check_type_argument_count(tcx, b.trait_ref.path.span, parameters.types().len(), 0, 0); } if parameters.lifetimes().len() > 0{ report_lifetime_number_error(tcx, b.trait_ref.path.span, parameters.lifetimes().len(), 0); } </ins> continue; // success } }

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.
Change:
self.scc_universes[scc] } <del> /// Once region solving has completed, this function will return /// the member constraints that were applied to the value of a given /// region `r`. See `AppliedMemberConstraint`. pub(crate) fn applied_member_constraints(&self, r: RegionVid) -> &[AppliedMemberConstraint] { let scc = self.constraint_sccs.scc(r); </del> <ins> /// Once region solving has completed, this function will return the member constraints that /// were applied to the value of a given SCC `scc`. See `AppliedMemberConstraint`. pub(crate) fn applied_member_constraints( &self, scc: ConstraintSccIndex, ) -> &[AppliedMemberConstraint] { </ins> binary_search_util::binary_search_slice( &self.member_constraints_applied, |applied| applied.member_region_scc,

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
use rustc_data_structures::fx::FxHashMap; use rustc_middle::bug; <del> use rustc_middle::ty::{self, Instance, Ty, TyCtxt, TypeFoldable}; </del> <ins> use rustc_middle::ty::{self, Instance, Ty, TyCtxt, TypeFoldable, TypeVisitableExt}; </ins> use rustc_target::abi::call::{Conv, FnAbi, PassMode}; use tracing::instrument;

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label A-sanitizers
Change:
with explanations of how to use various things, as well as example code for accomplishing various tasks. <ins> <div> <form action="std/index.html" method="get"> <input type="search" name="search"/> <button>Search</button> </form> </div> </ins> ## The Rustc Book [The Rustc Book](rustc/index.html) describes the Rust compiler, `rustc`.

Discussion:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.