jiebi/CodeConvo huggingface dataset:
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: [[package]] name = "gccjit" version = "1.0.0" <del> source = "git+https://github.com/antoyo/gccjit.rs#eefb8c662d61477f34b7c32d26bcda5f1ef08432" </del> <ins> source = "git+https://github.com/antoyo/gccjit.rs#fe242b7eb26980e6c78859d51c8d4cc1e43381a3" </ins> dependencies = [ "gccjit_sys", ]
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: [[package]] name = "gccjit_sys" version = "0.0.1" <del> source = "git+https://github.com/antoyo/gccjit.rs#eefb8c662d61477f34b7c32d26bcda5f1ef08432" </del> <ins> source = "git+https://github.com/antoyo/gccjit.rs#fe242b7eb26980e6c78859d51c8d4cc1e43381a3" </ins> dependencies = [ <del> "libc 0.1.12", </del> <ins> "libc", </ins> ] [[package]]
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: checksum = "7fcd999463524c52659517fe2cea98493cfe485d10565e7b0fb07dbba7ad2753" dependencies = [ "cfg-if", <del> "libc 0.2.112", </del> <ins> "libc", </ins> "wasi", ]
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "62b467343b94ba476dcb2500d242dadbb39557df889310ac77c5d99100aaac33" dependencies = [ <del> "libc 0.2.112", </del> <ins> "libc", </ins> ] [[package]]
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: dependencies = [ "fm", "getopts", <del> "libc 0.2.112", </del> <ins> "libc", </ins> "num_cpus", "termcolor", "threadpool",
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: [[package]] name = "libc" <del> version = "0.1.12" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e32a70cf75e5846d53a673923498228bbec6a8624708a9ea5645f075d6276122" [[package]] name = "libc" </del> version = "0.2.112" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1b03d17f364a3a042d5e5d46b053bbbf82c92c9430c592dd4c064dc6ee997125"
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: checksum = "05499f3756671c15885fee9034446956fff3f243d6077b91e5767df161f766b3" dependencies = [ "hermit-abi", <del> "libc 0.2.112", </del> <ins> "libc", </ins> ] [[package]]
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "2e7573632e6454cf6b99d7aac4ccca54be06da05aca2ef7423d22d27d4d4bcd8" dependencies = [ <del> "libc 0.2.112", </del> <ins> "libc", </ins> "rand_chacha", "rand_core", "rand_hc",
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: checksum = "dac1c663cfc93810f88aed9b8941d48cabf856a1b111c29a40439018d870eb22" dependencies = [ "cfg-if", <del> "libc 0.2.112", </del> <ins> "libc", </ins> "rand", "redox_syscall", "remove_dir_all",
Code change:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.

Related discussion:
text: source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "9f200f5b12eb75f8c1ed65abd4b2db8a6e1b138a20de009dacee265a2498f3f6" dependencies = [ <del> "libc 0.2.112", </del> <ins> "libc", </ins> ] [[package]]
Code change:
<!-- 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. --You need rustc built with debug assertions in order to reproduce this! <!-- 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

Related discussion:
text: // index position where it *should have been*, which is *after* the previous one. if let Some(provided_idx) = provided_idx { prev = provided_idx.index() as i64; <ins> continue; </ins> } let idx = ProvidedIdx::from_usize((prev + 1) as usize); <del> if let None = provided_idx && let Some((_, arg_span)) = provided_arg_tys.get(idx) { </del> <ins> if let Some((_, arg_span)) = provided_arg_tys.get(idx) { prev += 1; </ins> // There is a type that was *not* found anywhere, so it isn't a move, but a // replacement and we look at what type it should have been. This will allow us // To suggest a multipart suggestion when encountering `foo(1, "")` where the def
Code change:
<!-- 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. --You need rustc built with debug assertions in order to reproduce this! <!-- 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

Related discussion:
text: <ins> struct A; struct B; fn f(b1: B, b2: B, a2: C) {} //~ ERROR E0412 fn main() { f(A, A, B, C); //~ ERROR E0425 //~^ ERROR E0061 } </ins>
Code change:
<!-- 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. --You need rustc built with debug assertions in order to reproduce this! <!-- 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

Related discussion:
text: <ins> error[E0412]: cannot find type `C` in this scope --> $DIR/issue-109831.rs:4:24 | LL | struct A; | --------- similarly named struct `A` defined here ... LL | fn f(b1: B, b2: B, a2: C) {} |                        ^ | help: a struct with a similar name exists | LL | fn f(b1: B, b2: B, a2: A) {} |                        ~ help: you might be missing a type parameter | LL | fn f<C>(b1: B, b2: B, a2: C) {} |     +++ error[E0425]: cannot find value `C` in this scope --> $DIR/issue-109831.rs:7:16 | LL | struct A; | --------- similarly named unit struct `A` defined here ... LL |     f(A, A, B, C); |                ^ help: a unit struct with a similar name exists: `A` error[E0061]: this function takes 3 arguments but 4 arguments were supplied --> $DIR/issue-109831.rs:7:5 | LL |     f(A, A, B, C); |     ^ -  -     - unexpected argument |       |  | |       |  expected `B`, found `A` |       expected `B`, found `A` | note: function defined here --> $DIR/issue-109831.rs:4:4 | LL | fn f(b1: B, b2: B, a2: C) {} |    ^ -----  -----  ----- help: remove the extra argument | LL -     f(A, A, B, C); LL +     f(/* B */, /* B */, B); | error: aborting due to 3 previous errors Some errors have detailed explanations: E0061, E0412, E0425. For more information about an error, try `rustc --explain E0061`. </ins>
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: let tcx = self.tcx; let def_id = instance.def_id(); <del> let containing_scope = get_containing_scope(self, instance); </del> <ins> let (containing_scope, is_method) = get_containing_scope(self, instance); </ins> let span = tcx.def_span(def_id); let loc = self.lookup_debug_loc(span.lo()); let file_metadata = file_metadata(self, &loc.file);
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: } } <del> unsafe { return llvm::LLVMRustDIBuilderCreateFunction( </del> <ins> // When we're adding a method to a type DIE, we only want a DW_AT_declaration there, because // LLVM LTO can't unify type definitions when a child DIE is a full subprogram definition. // When we use this `decl` below, the subprogram definition gets created at the CU level // with a DW_AT_specification pointing back to the type's declaration. let decl = is_method.then(|| unsafe { llvm::LLVMRustDIBuilderCreateMethod( DIB(self), containing_scope, name.as_ptr().cast(), name.len(), linkage_name.as_ptr().cast(), linkage_name.len(), file_metadata, loc.line, function_type_metadata, flags, spflags & !DISPFlags::SPFlagDefinition, template_parameters, ) }); return unsafe { llvm::LLVMRustDIBuilderCreateFunction( </ins> DIB(self), containing_scope, name.as_ptr().cast(),
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,
Code change:
If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim

Related discussion:
text: names } <ins> /// Returns a scope, plus `true` if that's a type scope for "class" methods, /// otherwise `false` for plain namespace scopes. </ins> fn get_containing_scope<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>, instance: Instance<'tcx>, <del> ) -> &'ll DIScope { </del> <ins> ) -> (&'ll DIScope, bool) { </ins> // First, let's see if this is a method within an inherent impl. Because // if yes, we want to make the result subroutine DIE a child of the // subroutine's self-type. <del> let self_type = cx.tcx.impl_of_method(instance.def_id()).and_then(|impl_def_id| { </del> <ins> if let Some(impl_def_id) = cx.tcx.impl_of_method(instance.def_id()) { </ins> // If the method does *not* belong to a trait, proceed if cx.tcx.trait_id_of_impl(impl_def_id).is_none() { let impl_self_ty = cx.tcx.subst_and_normalize_erasing_regions(