jiebi/CodeConvo huggingface dataset:
Change:
pub mod huge_amount_of_consts { include!(concat!(env!("OUT_DIR"), "/huge_amount_of_consts.rs")); } <ins> /// Very long code text `hereIgoWithLongTextBecauseWhyNotAndWhyWouldntI`. pub mod long_code_block {} </ins>

Discussion:
Otherwise, if too long we can't read them: ! With rule: !
You probs want so that it tries to not wrap mid-word (but still does if it can't do otherwise).
With your suggestion it gives: ! It's weird but in a different way haha.
We can tell the browser where to break words by inserting in the right places. E.g. . Together with some other CSS properties that should give us full control where it'll do the breaking.
it's not clear to me that makes wrapping word-aware (that would be quite a task!) In other words, vs differ only in whether the wrap : Emphasis mine. We don't explicitly use min-content in our CSS as far as I can tell, but looking at the screenshots shared, perhaps it is introduced somewhere by browser intrinsics? Long story short, I think we should use . It produces nicer results in these screenshots, and isn't documented to provide benefits that we care about.
I'm certainly not a CSS expert, I just meant "let's not break idents in the middle" and assumed would be enough for that. It seems like gave the proper answer for breaking correctly around instead of in the middle of the words.
Change:
<ins> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` trait A { type Assoc: ?Sized; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { let x: Foo<()>; } </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
<del> error[E0463]: can't find crate for `meta` --> $DIR/meta.rs:5:5 | LL | use meta; |     ^^^^ can't find crate error: aborting due to previous error For more information about this error, try `rustc --explain E0463`. </del>

Discussion:
Taken from this internals thread: A module named is shadowed leading to misleading error messages. was reserved as a built-in crate name in 2018 edition, but the error message does not indicate this. I tried this code: Above code compiled with This is expected to indicated that is a reserved crate name. Instead, the following error is reported: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Error: Parsing assign command in failed: ...'tbot claim' ' ?'... Please let know if you're having trouble with this bot.
claim
It's not forbidden as a module name, this obviously works: I think the confusion arises from that fact that this works without : But those are uniform imports (or at least I think that's what they're called), and only resolve to the surrounding scope if unambiguous (which it is for due to the. I'm guessing the right fix here is to add more information to the error suggesting that if the intention wasn't to refer to a crate, or etc. should/can be used explicitly. (EDIT: I went to the internals thread to reply, and it's from March 2019 apparently, and also was mentioned there, but I guess the fact that the name is perfectly fine outside of wasn't brought up) cc
I believe the "fix" was mentioned in a reddit thread linking to the internals thread, but I forgot to mention it. I will reword the issue as it is misworded, as you pointed out. Lastly, what you suggested for a fix lines up with what I was expecting. Also, now you know how deep my backlog of todo items is.
Change:
<ins> // Previously this ICE'd because `fn g()` would be lowered, but the block associated with `fn f()` // wasn't. // compile-flags: --crate-type=lib extern "C" { fn f() { //~^ incorrect function inside `extern` block fn g() {} } } </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. --: Also occurs on nightly at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Semicolon is not the main problem here. Standalone semicolons are allowed as items inside function body. Second function definition would be OK if not for the extern "C" block — AFAIK only function declarations are allowed there, so is not valid syntax.
Prioritized as as per .7B.3B.60)
claim
A possibly clearer repro:
glacier ""
The previous issue has been fixed, let's try again (sorry for the noise!). glacier ""
Change:
<ins> With a code sample, that has an error: ```rust fn main() { let x = 234 // no semicolon here! oh no! } ``` </ins>

Discussion:
The repro repository has everything: Expected behavior is that the diagnostics have: , but they currently have .
cc (as per )
Thanks for opening the issue! I'm surprised since it's an issue that was supposed to be fixed in Just to confirm: which rustc version do you use? Also cc since you're the one who fixed this bug.
This happened with 1.81 most likely — I would take the few secs to check but I’m on a phone right now.
The doctest system needs to use the same infrastructure as the rest of rustdoc.
I can confirm this does fix my repro: ! Would you like a separate issue for the part where it says when really it could normalize the path and just say ?
Yes please!
filed as
Thanks! Gonna take a look in the next days if someone else didn't do it before then.
Change:
let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrOk); </del> <ins> assert_eq!(result, TrOk); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.
Change:
unrecognized representation hint .help = valid reprs are `Rust` (default), `C`, `align`, `packed`, `transparent`, `simd`, `i8`, `u8`, `i16`, `u16`, `i32`, `u32`, `i64`, `u64`, `i128`, `u128`, `isize`, `usize` <ins> passes_unstable_attr_for_already_stable_feature = can't mark as unstable using an already stable feature .label = this feature is already stable .item = the stability attribute annotates this item .help = consider removing the attribute </ins> passes_unused = unused attribute .suggestion = remove this attribute

Discussion:
This should probably not be accepted: is already stable, so having an unstable function under this feature makes no sense. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Should we also reject features that don't exist? Right now, this test would fail (because it would compile without problems)
"unstable" attributes is how library features come into existence. So yes we should accept features that do not yet exist.
Change:
where F: for<'scope> FnOnce(&'scope Scope<'scope, 'env>) -> T, { <ins> // We put the `ScopeData` into an `Arc` so that other threads can finish their // `decrement_num_running_threads` even after this function returns. </ins> let scope = Scope { <del> data: ScopeData { </del> <ins> data: Arc::new(ScopeData { </ins> num_running_threads: AtomicUsize::new(0), main_thread: current(), a_thread_panicked: AtomicBool::new(false), <del> }, </del> <ins> }), </ins> env: PhantomData, scope: PhantomData, };

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
<ins> fn thing(x: impl FnOnce(&u32, &u32, u32)) {} fn main() { let f = | _ , y: &u32 , z | (); thing(f); //~^ ERROR mismatched types //~^^ ERROR mismatched types let f = | x, y: _  , z: u32 | (); thing(f); //~^ ERROR mismatched types //~^^ ERROR mismatched types //~^^^ ERROR implementation of `FnOnce` is not general enough //~^^^^ ERROR implementation of `FnOnce` is not general enough } </ins>

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim
Change:
} ast::ExprAssign(lhs, rhs) => { check_assignment(fcx, lhs, rhs, id); <ins> let tcx = fcx.tcx(); if !ty::expr_is_lval(tcx, fcx.ccx.method_map, lhs) { tcx.sess.span_err(lhs.span, "illegal left-hand side expression"); } </ins> let lhs_ty = fcx.expr_ty(lhs); let rhs_ty = fcx.expr_ty(rhs); if ty::type_is_error(lhs_ty) || ty::type_is_error(rhs_ty) {

Discussion:
When compiling the following code: I get the error: Compiled with:
I also just hit this today. An even simpler test case:
Reproduced with (both cases). Interestingly, rustc warns that X0 and X1 don't need to be mutable on the first case.
Similar ICE with structs:
The simplest case I think:
It's because assumes only one of will come but it met . So seems easy to fix, but what about tuples/structs? is also not allowed, right? I initially thought it is allowed because is. But previous discussions seem that it's not: , .
My impression is that isn't supposed to be allowed. That said, it would be kinda neat if it was. Right now I'm writing the same 3 lines over and over that look like and I'd love to be able to just say
I forgot to mention about mutability; currently is obsolete, and (heard from irc) it may be because it's confusing that immutable tuples are with . I don't know any previous discussion about it. anyone? If it is true, should be disallowed in the same manner, because is immutable while and are. Anyway, I agree with it's not cool to unpack manually.
Clearly something in the compiler is not checking that the LHS of an assignment is actually an lvalue. Kind of amusing. Rather surprising that this gets through borrowck, I'll have to look at that. It's probably assuming that an earlier pass would have caught such cases. Anyway, it'd be nice to permit , certainly, but it is not currently allowed. I think that'd be a post-Rust 1.0 sort of extension. I previously thought it would introduce horrible ambiguities into parsing, but I realize now that it would not, so long as you only have two cases: , which assigns to a pattern, and which always declares new bindings, and , which always overwrites existing lvalues.
Change:
TyKind::Slice(ref ty) => Slice(box ty.clean(cx)), TyKind::Array(ref ty, ref length) => { let def_id = cx.tcx.hir().local_def_id(length.hir_id); <del> let length = match cx.tcx.const_eval_poly(def_id.to_def_id()) { Ok(length) => { print_const(cx, ty::Const::from_value(cx.tcx, length, cx.tcx.types.usize)) } Err(_) => cx .sess() .source_map() .span_to_snippet(cx.tcx.def_span(def_id)) .unwrap_or_else(|_| "_".to_string()), }; </del> <ins> // NOTE(min_const_generics): We can't use `const_eval_poly` for constants // as we currently do not supply the parent generics to anonymous constants // but do allow `ConstKind::Param`. // // `const_eval_poly` tries to to first substitute generic parameters which // results in an ICE while manually constructing the constant and using `eval` // does nothing for `ConstKind::Param`. let ct = ty::Const::from_anon_const(cx.tcx, def_id); let param_env = cx.tcx.param_env(def_id); let length = print_const(cx, ct.eval(cx.tcx, param_env)); </ins> Array(box ty.clean(cx), length) } TyKind::Tup(ref tys) => Tuple(tys.clean(cx)),

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. --The following code compiles just fine but when trying to run on it I get the error described below <!-- 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 --
Making this even more strange, this does not panic with instead.
<details<summaryBacktrace</summary</detailsRustdoc code:
The main function is not necessary, it also crashes on
Yeah this one is beyond me, I have no idea why this is breaking.
This never worked with ; on it says the feature isn't recognized and on it crashes.
Huh, I built that last code snippet in the Rust Playground and it compiled fine:
yes, it only crashes with rustdoc, which isn't available on the playground.
Oops, I missed that part. Sorry about that!
Feel free to ping me on all issues related to const generics claim
Thanks for fixing this!
Change:
blanket_impl: None, }), cx, <del> )); </del> <ins> ); item.attrs = merge_attrs(cx, parent_module.into(), load_attrs(cx, did), attrs); debug!("merged_attrs={:?}", item.attrs); ret.push(item); </ins> } fn build_module(cx: &DocContext<'_>, did: DefId, visited: &mut FxHashSet<DefId>) -> clean::Module {

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
self.ann.nested(self, Nested::Body(body)); } hir::ImplItemKind::TyAlias(ref ty) => { <del> self.print_associated_type(ii.ident, None, Some(ty)); </del> <ins> self.print_associated_type(ii.ident, &ii.generics, None, Some(ty)); </ins> } hir::ImplItemKind::OpaqueTy(bounds) => { self.word_space("type");

Discussion:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form
Change:
cx: &CodegenCx<'ll, 'tcx>, pointee_ty: Ty<'tcx>, ) -> Option<FatPtrKind> { <del> let layout = cx.layout_of(pointee_ty); </del> <ins> let pointee_tail_ty = cx.tcx.struct_tail_erasing_lifetimes(pointee_ty, cx.param_env()); let layout = cx.layout_of(pointee_tail_ty); trace!( "fat_pointer_kind: {:?} has layout {:?} (is_unsized? {})", pointee_tail_ty, layout, layout.is_unsized() ); </ins> if !layout.is_unsized() { return None; } <del> match *pointee_ty.kind() { </del> <ins> match *pointee_tail_ty.kind() { </ins> ty::Str | ty::Slice(_) => Some(FatPtrKind::Slice), ty::Dynamic(..) => Some(FatPtrKind::Dyn), <del> ty::Adt(..) | ty::Tuple(..) if matches!(layout.variants, Variants::Single { .. }) => { let last_field_index = layout.fields.count() - 1; debug_assert!( (0..last_field_index) .all(|field_index| { !layout.field(cx, field_index).is_unsized() }) ); let unsized_field = layout.field(cx, last_field_index); debug_assert!(unsized_field.is_unsized()); fat_pointer_kind(cx, unsized_field.ty) } </del> ty::Foreign(_) => { // Assert that pointers to foreign types really are thin: debug_assert_eq!( <del> cx.size_of(cx.tcx.mk_imm_ptr(pointee_ty)), </del> <ins> cx.size_of(cx.tcx.mk_imm_ptr(pointee_tail_ty)), </ins> cx.size_of(cx.tcx.mk_imm_ptr(cx.tcx.types.u8)) ); None

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. --glacier <!-- 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. --: Note: you need a build with rustc debug assertions enabled! <!-- 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
Change:
<ins> error[E0764]: mutable references are not allowed in the final value of constants --> $DIR/issue-76510.rs:5:29 | LL | const S: &'static mut str = &mut " hello "; |                             ^^^^^^^^^^^^^^ error[E0658]: mutation through a reference is not allowed in constants --> $DIR/issue-76510.rs:5:29 | LL | const S: &'static mut str = &mut " hello "; |                             ^^^^^^^^^^^^^^ | = note: see issue #57349 <https://github.com/rust-lang/rust/issues/57349> for more information = help: add `#![feature(const_mut_refs)]` to the crate attributes to enable error[E0596]: cannot borrow data in a `&` reference as mutable --> $DIR/issue-76510.rs:5:29 | LL | const S: &'static mut str = &mut " hello "; |                             ^^^^^^^^^^^^^^ cannot borrow as mutable error[E0080]: it is undefined behavior to use this value --> $DIR/issue-76510.rs:5:1 | LL | const S: &'static mut str = &mut " hello "; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered mutable reference in a `const` | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. = note: the raw bytes of the constant (size: 8, align: 4) { ╾─alloc2──╼ 07 00 00 00                         │ ╾──╼.... } error: aborting due to 4 previous errors Some errors have detailed explanations: E0080, E0596, E0658, E0764. For more information about an error, try `rustc --explain E0080`. </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
A slightly more minimal example that does not use unsafe:
This bug was introduced in 1.46. Rustc 1.45.2 rightfully rejects the code, 37 - 1.44 ICEs with
Run cargo bisect on this: regression in Given that the panic is in , the likely culprit is PR because of the changes to
No longer ICEs since