jiebi/CodeConvo huggingface dataset:
Change:
path: String, desc: String, parent: Option<DefId>, <ins> parent_idx: Option<usize>, </ins> search_type: Option<IndexItemFunctionType>, } <ins> impl ToJson for IndexItem { fn to_json(&self) -> Json { assert_eq!(self.parent.is_some(), self.parent_idx.is_some()); let mut data = Vec::with_capacity(6); data.push((self.ty as usize).to_json()); data.push(self.name.to_json()); data.push(self.path.to_json()); data.push(self.desc.to_json()); data.push(self.parent_idx.to_json()); data.push(self.search_type.to_json()); Json::Array(data) } } </ins> /// A type used for the search index. struct Type { name: Option<String>, } <del> impl fmt::Display for Type { /// Formats type as {name: $name}. fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { // Wrapping struct fmt should never call us when self.name is None, // but just to be safe we write `null` in that case. </del> <ins> impl ToJson for Type { fn to_json(&self) -> Json { </ins> match self.name { <del> Some(ref n) => write!(f, "{{"name":"{}"}}", n), None => write!(f, "null") </del> <ins> Some(ref name) => { let mut data = BTreeMap::new(); data.insert("name".to_owned(), name.to_json()); Json::Object(data) }, None => Json::Null </ins> } } }

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> use crate::mem::{size_of, transmute_copy}; </ins> use crate::ptr::write_bytes; pub(super) trait SpecFill<T> {

Discussion:
Specialized slice::fill implementations are not inlined even though they would compile down to pretty much just a single memset-call. The function below represents manual inlining of . () I haven’t tested it in any way, but I suspect that this can be fixed by marking as . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: C-enhancement, T-libs-impl, I-slow, E-easy
claim
Don't you need at the very least (but not necessarily ) to actually guarantee cross-crate-inlining eligibility with the default no-LTO profile? It'd certainly make sense to add that to all of the impls in IMO.
It being generic is sufficient for being eligible because the monomorphized function is only created in the consuming crate once all the generics have been filled in. Adding on top just encourages it further.
Change:
<ins> struct What<W = usize, X = Vec<W>>(W, X); fn main() { let mut b: What<usize> = What(5, vec![1, 2, 3]); let c: What<usize, String> = What(1, String::from("meow")); b = c; //~ ERROR mismatched types let mut f: What<usize, Vec<String>> = What(1, vec![String::from("meow")]); let e: What<usize> = What(5, vec![1, 2, 3]); f = e; //~ ERROR mismatched types } </ins>

Discussion:
or The current error message does not tell me the mismatch is in rather than in . It is also inconsistent with the error message I would get if has without the default types. When removing the default for the first parameter (which is not the mismatched one) like this: the error message is clearer: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> //@ known-bug: #118185 fn main() { let target: Target = create_target(); target.get(0); // correct arguments work target.get(10.0); // CRASH HERE } // must be generic fn create_target<T>() -> T { unimplemented!() } // unimplemented trait, but contains function with the same name pub trait RandomTrait { fn get(&mut self); // but less arguments } struct Target; impl Target { // correct function with arguments pub fn get(&self, data: i32) { unimplemented!() } } </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. --Hello, I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function ( from leptos) and inside recursivelly calling macro. Here is how approximately it looks: <!-- 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. --Fails on both nightly and stable, backtrace if from nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsHope this helps and thank for your work.
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. label +S-needs-repro -E-needs-mcve
I think I encountered the same bug. A minimal example is below. I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing. : Also fails on nightly. <details<summary<strongnightly ructc-</strong</summary<p</p</details
Maybe inside rollup ? cc
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. When doing a bisection I get nightly-2023-05-16.
Change:
<del> Subproject commit c65fbc49d7b9269b277b7207f1044ee851f16b16 </del> <ins> Subproject commit 945f007c0d305c3ec069b5e5d911ef783f6d70e7 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I think fixes this so I opened . Feel free to close it if it's invalid.
Change:
<ins> // Regression test for issue 115264 // Tests that retrieving the ident of 'foo' variable in // the pattern inside main() does not cause an ICE // check-pass struct X { foo: i32, } #[allow(unused_variables)] fn main() { let X { #[doc(alias = "StructItem")] foo } = X { foo: 123 }; } </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 --
Regression in nightly-2022-08-16 commit[0] 2022-08-14: Auto merge of - GuillaumeGomez:merge-html-elements-together, r=notriddle commit[1] 2022-08-14: Auto merge of - matthiaskrgr:rollup-734hkpt, r=matthiaskrgr commit[2] 2022-08-15: Auto merge of - compiler-errors:as-a-treat, r=jackh726 commit[3] 2022-08-15: Auto merge of - austinabell:skip_optimization, r=Mark-Simulacrum commit[4] 2022-08-15: Auto merge of - ehuss:even-more-attribute-validation, r=cjgillot commit[5] 2022-08-15: Auto merge of - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser commit[6] 2022-08-15: Auto merge of - matthiaskrgr:rollup-9450lzs, r=matthiaskrgr commit[7] 2022-08-15: Auto merge of - matthiaskrgr:rollup-f1zur58, r=matthiaskrgr
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Originates in PR . We are returning for although it does have an ident: The fix would be to start returning the ident. suffers from the same problem and may need the same treatment.
Change:
edition: None, } } <ins> } impl LangString { </ins> fn parse_without_check( string: &str, allow_error_code_check: ErrorCodes,

Discussion:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first
Change:
returned = checkReturned(ty, output, true); if (output.name === "*" || returned === true) { in_args = false; <del> var module = false; </del> <ins> var is_module = false; </ins> if (input === "*") { <del> module = true; </del> <ins> is_module = true; </ins> } else { var allFound = true; for (var it = 0; allFound === true && it < inputs.length; it++) {

Discussion:
I was trying to find in rustdoc, but that doesn't show up anywhere if I just search for : It does show up if I search for () so there's a workaround, but I think it'd be nice if when I type an exact name, things with that exact name show up at the top, or something.
It's supposed to, so some adjustments need to be done on the "search engine". I'll take a look.
Change:
/// The module can be different if this is a re-export with added documentation. crate fn collapsed_doc_value_by_module_level(&self) -> FxHashMap<Option<DefId>, String> { let mut ret = FxHashMap::default(); <ins> if self.doc_strings.len() == 0 { return ret; } let last_index = self.doc_strings.len() - 1; </ins> <del> for new_frag in self.doc_strings.iter() { </del> <ins> for (i, new_frag) in self.doc_strings.iter().enumerate() { </ins> let out = ret.entry(new_frag.parent_module).or_default(); add_doc_fragment(out, new_frag); <ins> if i == last_index { out.pop(); } </ins> } ret }

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
<ins> error: unnecessary parentheses around `let` scrutinee expression --> $DIR/issue-74883-unused-paren-baren-yield.rs:14:29 | LL |         while let Some(_) = ({yield}) {} |                             ^^^^^^^^^ help: remove these parentheses | note: the lint level is defined here --> $DIR/issue-74883-unused-paren-baren-yield.rs:3:24 | LL | #![deny(unused_braces, unused_parens)] |                        ^^^^^^^^^^^^^ error: unnecessary parentheses around `let` scrutinee expression --> $DIR/issue-74883-unused-paren-baren-yield.rs:15:29 | LL |         while let Some(_) = ((yield)) {} |                             ^^^^^^^^^ help: remove these parentheses error: unnecessary braces around block return value --> $DIR/issue-74883-unused-paren-baren-yield.rs:16:10 | LL |         {{yield}}; |          ^^^^^^^ help: remove these braces | note: the lint level is defined here --> $DIR/issue-74883-unused-paren-baren-yield.rs:3:9 | LL | #![deny(unused_braces, unused_parens)] |         ^^^^^^^^^^^^^ error: unnecessary parentheses around block return value --> $DIR/issue-74883-unused-paren-baren-yield.rs:17:10 | LL |         {( yield )}; |          ^^^^^^^^^ help: remove these parentheses error: unnecessary braces around `let` scrutinee expression --> $DIR/issue-74883-unused-paren-baren-yield.rs:21:29 | LL |         while let Some(_) = {(yield)} {} |                             ^^^^^^^^^ help: remove these braces error: unnecessary parentheses around block return value --> $DIR/issue-74883-unused-paren-baren-yield.rs:21:30 | LL |         while let Some(_) = {(yield)} {} |                              ^^^^^^^ help: remove these parentheses error: unnecessary braces around `let` scrutinee expression --> $DIR/issue-74883-unused-paren-baren-yield.rs:24:29 | LL |         while let Some(_) = {{yield}} {} |                             ^^^^^^^^^ help: remove these braces error: unnecessary braces around block return value --> $DIR/issue-74883-unused-paren-baren-yield.rs:24:30 | LL |         while let Some(_) = {{yield}} {} |                              ^^^^^^^ help: remove these braces error: aborting due to 8 previous errors </ins>

Discussion:
I tried this code: I expected to see this happen: no warning Instead, this happened: if I follow the suggestion, then compilation fails: ( takes an optional expression, not wrapping it in parentheses means the block becomes that expression, and the is then missing a block). - `rustc 1.47.0-nightly (2020-07-27 )
The lint is a rustc lint, not a Clippy lint. This issue should probably be moved to the rust-lang/rust repo. can you move this issue, please?
Done, thanks
Change:
<ins> pub fn test<const N: usize, T>() {} </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. --Not sure how this passes the test suite :upsidedownface: Original code from reduced &lt;!-- 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. --: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
This is caused by The fix is to either enable in - this improves diagnostics but pessimizes compile times for successful compilations. do not use spans of const generic parameters from other crates in diagnostics - this makes diagnostics worse but optimizes compile times for successful compilations.
I can't reproduce this either locally or in playground.
Weird, I can still repro locally with and master :shrug:
mcve from a different file:
This is also weird for me to reproduce: I must be doing something wrong, both my and toolchains are the same rustc/cargo commits ( and ): a (or rustc) ICEs on that stdsimd repro a (or rustc) does not a ICEs (but not rustc)
Yeah, something is very weird. I didn't manage to properly this when I tried. I also failed to reproduce on playground or godbolt, but I have encountered maybe around 20 more or less similar files that hit this ICE when checking reports.
Same for me, found a nightly but failed with the CI artifacts. If somehow invoking differently manually or with/without rustup makes things work or fail, maybe the tool also invokes things in the way that doesn't repro...
I forgot to mention: this does also reproduce on master and reverting seems to fix the ICE indeed, as vadim suggested above.
I'm going to remove has-mcve since we're not sure why it sometimes doesn't ICE.
I think this is the better solution. Otherwise, we'll have more and more special cases in diagnostic code which is already very complex.
Couple more reproducers:
Change:
let def_id = instance.def_id(); let upvars_ty = match tcx.type_of(def_id).skip_binder().kind() { ty::Closure(..) => Some(args.as_closure().tupled_upvars_ty()), <del> ty::Coroutine(..) => Some(args.as_coroutine().tupled_upvars_ty()), </del> <ins> ty::Coroutine(..) => { assert_eq!( args.as_coroutine().kind_ty(), tcx.types.unit, "polymorphization does not support coroutines from async closures" ); Some(args.as_coroutine().tupled_upvars_ty()) } </ins> _ => None, }; let has_upvars = upvars_ty.is_some_and(|ty| !ty.tuple_fields().is_empty());

Discussion:
<!-- [31mICE[0m: Rustc '-Zprint-mono-items=eager -Zpolymorphize=on --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: coroutine constructed with incorrect number of substitutions'', 'thread 'rustc' panicked at 'assertion failed: coroutine constructed with incorrect number of substitutions'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [collectandpartitionmonoitems] collectandpartitionmonoitems [exported_symbols] collecting exported symbols for crate --
without debug assertions: &lt;!-- [31mICE[0m: Rustc '-Zprint-mono-items=eager -Zpolymorphize=on --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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<!-- query stack: [collectandpartitionmonoitems] collectandpartitionmonoitems [exported_symbols] collecting exported symbols for crate --
Regression in nightly-2024-02-07 cc
Change:
self.note_and_explain_region(db, "...does not overlap ", region2, ""); } <del> RegionsInsufficientlyPolymorphic(_, conc_region) => { </del> <ins> RegionsInsufficientlyPolymorphic(_, conc_region, _) => { </ins> self.note_and_explain_region(db, "concrete lifetime that was found is ", conc_region, ""); } <del> RegionsOverlyPolymorphic(_, &ty::ReVar(_)) => { </del> <ins> RegionsOverlyPolymorphic(_, &ty::ReVar(_), _) => { </ins> // don't bother to print out the message below for // inference variables, it's not very illuminating. } <del> RegionsOverlyPolymorphic(_, conc_region) => { </del> <ins> RegionsOverlyPolymorphic(_, conc_region, _) => { </ins> self.note_and_explain_region(db, "expected concrete lifetime is ", conc_region, ""); }

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
pub trait InferCtxtBuilderExt<'tcx> { fn enter_canonical_trait_query<K, R>( <del> &mut self, </del> <ins> self, </ins> canonical_key: &Canonical<'tcx, K>, operation: impl FnOnce(&ObligationCtxt<'_, 'tcx>, K) -> Result<R, NoSolution>, ) -> Result<CanonicalQueryResponse<'tcx, R>, NoSolution>

Discussion:
This used to compile and now ICEs: Compiles on Stable version: 1.70.0 Regressed in 1.71.0-beta.6 (2023-07-08 ) I guess it is , but this shouldn't be in beta? <details<summary<strongBacktrace</strong</summary<p</p</details
Bisection results: searched nightlies: from nightly-2023-05-20 to nightly-2023-07-14 regressed nightly: nightly-2023-06-25 searched commit range: regressed commit: ( -), cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
use std::mem; use std::num::NonZeroUsize; use std::ops::ControlFlow; <ins> use std::ptr::NonNull; </ins> use std::{fmt, str}; pub use crate::ty::diagnostics::*;

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)
Change:
// Make the default table accessible self.cmd.arg("--export-table"); <ins> // Rust code should never have warnings, and warnings are often // indicative of bugs, let's prevent them. self.cmd.arg("--fatal-warnings"); </ins> let mut cmd = Command::new(""); ::std::mem::swap(&mut cmd, &mut self.cmd); cmd

Discussion:
A thing works fine when compiled with stable rust, but fails at runtime with nightly. I tried this code: I expected this to happen: It'd compile and work, just like it used to. Instead, this happened: It appears it has to do something with Specifically, changing them to take f64 instead fails with: :
Now pushed to stable 1.29. Great.
Cc
Ah it looks like this is a symbol conflict error: You'll want to rename your import as it conflicts with the symbol in compiler-rt
Oh, I see, thanks!