jiebi/CodeConvo huggingface dataset:
Change:
config::CrateTypeDylib | config::CrateTypeProcMacro => MetadataKind::Compressed, } <del> }).max().unwrap(); </del> <ins> }).max().unwrap_or(MetadataKind::None); </ins> if kind == MetadataKind::None { return (metadata_llcx,

Discussion:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #!

[nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked.

this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // test for issue #30244 #[derive(Copy, Clone)] struct Array { arr: [[u8; 256]; 4] } pub fn main() {} </ins>

Discussion:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.
Change:
builder.add_rustc_lib_path(compiler, &mut cargo); <del> builder.run(&mut cargo.into()); </del> <ins> // FIXME: Disable clippy tests for now, they're failing on master // (generally this would mean a toolstate failure but we don't have // toolstate for clippy anymore). // builder.run(&mut cargo.into()); </ins> } }

Discussion:
fails currently due to However, the toolstate is green nevertheless. Looks like somehow toolstate tracking is broken. Due to this, we currently ship a broken Miri via rustup. Cc
I can't make heads or tails of the log in It looks to me like tests weren't run at all?
Yeah that's expected, the dist builders only build the tools and do not test them. The tools builder tests them. Manifest creation (when the final toolchain is to rustup, as part of auto -master promotion) reads the toolstate JSON files and omits Miri if its tests failed. (So far, no other tool opted into using that system, as far as I know.)
But for some reason, the tools builder doesn't even seem to build Miri?!?
It runs the miri tests and shows that they fail. The toolstate processing after that is just not verbose enough to tell us what's up
It says But that did not even get to Miri. It stopped after another test failure: I think that's a clippy test. So what likely happened is that a clippy test failed, but for some reason, instead of aborting CI, that lead to all tools being marked as test-pass...
That line says ? And above some tests fail, but those are not Miri's tests.
Oh... right... maybe clippy tests failing cause all other tools not to get tested at all, thus leading to "successful" test results
And, notably, clippy tests failing do not block the PR from landing!
oh... right :facepalm: so... let's do this PR and figure out things in another try? rollup-
You did this in an issue, not sure what that is going to accomplish. :D
oops. I thought we were on the PR
Change:
"packed type cannot transitively contain a `#[repr(align)]` type" ); <del> let hir = tcx.hir(); let hir_id = hir.as_local_hir_id(def_spans[0].0.expect_local()); if let Node::Item(Item { ident, .. }) = hir.get(hir_id) { err.span_note( tcx.def_span(def_spans[0].0), &format!("`{}` has a `#[repr(align)]` attribute", ident), ); } </del> <ins> err.span_note( tcx.def_span(def_spans[0].0), &format!( "`{}` has a `#[repr(align)]` attribute", tcx.item_name(def_spans[0].0) ), ); </ins> if def_spans.len() > 2 { let mut first = true; for (adt_def, span) in def_spans.iter().skip(1).rev() { <del> let hir_id = hir.as_local_hir_id(adt_def.expect_local()); if let Node::Item(Item { ident, .. }) = hir.get(hir_id) { err.span_note( *span, &if first { format!( "`{}` contains a field of type `{}`", tcx.type_of(def.did), ident ) } else { format!("...which contains a field of type `{}`", ident) }, ); first = false; } </del> <ins> let ident = tcx.item_name(*adt_def); err.span_note( *span, &if first { format!( "`{}` contains a field of type `{}`", tcx.type_of(def.did), ident ) } else { format!("...which contains a field of type `{}`", ident) }, ); first = false; </ins> } }

Discussion:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.
Change:
<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/issue-74713.rs:4:17 | LL |         let _: &'a (); |                 ^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = help: add `#![feature(generic_const_exprs)]` to the crate attributes to enable error[E0308]: mismatched types --> $DIR/issue-74713.rs:3:10 | LL |       [(); { |  __________^ LL | |         let _: &'a (); LL | |     }]: | |_____^ expected `usize`, found `()` error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0658. For more information about an error, try `rustc --explain E0308`. </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. --: New backtrace: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis probably is the same as found in , except this hits on stable :)
17 - now ICE's 9 - 1.16 just error normally 6 - 1.8 also produce an ICE (unreachable code in ) 0 - 1.5 just error normally
This is has a similar cause to .
Assigning as and removing .
Since minconstgenerics stabilisation this now requires
Seems it has been fixed (finally) in the latest nightly, marking as
Triage: This still triggers ICE with a debug assertion, see for details.
Is there a known workaround to this ? I'm getting this error with the following:
I think I have found a duplicate. <!-- 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
from what I can tell this now works even with debug assertions? marking as needs-test.
Change:
<ins> error: free function without a body --> $DIR/issue-70736-async-fn-no-body-def-collector.rs:3:1 | LL | async fn free(); | ^^^^^^^^^^^^^^^- |                | |                help: provide a definition for the function: `{ <body> }` error: associated function in `impl` without body --> $DIR/issue-70736-async-fn-no-body-def-collector.rs:7:5 | LL |     async fn inherent(); |     ^^^^^^^^^^^^^^^^^^^- |                        | |                        help: provide a definition for the function: `{ <body> }` error[E0706]: functions in traits cannot be declared `async` --> $DIR/issue-70736-async-fn-no-body-def-collector.rs:11:5 | LL |     async fn associated(); |     -----^^^^^^^^^^^^^^^^^ |     | |     `async` because of this | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error: associated function in `impl` without body --> $DIR/issue-70736-async-fn-no-body-def-collector.rs:15:5 | LL |     async fn associated(); |     ^^^^^^^^^^^^^^^^^^^^^- |                          | |                          help: provide a definition for the function: `{ <body> }` error[E0706]: functions in traits cannot be declared `async` --> $DIR/issue-70736-async-fn-no-body-def-collector.rs:15:5 | LL |     async fn associated(); |     -----^^^^^^^^^^^^^^^^^ |     | |     `async` because of this | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error[E0053]: method `associated` has an incompatible type for trait --> $DIR/issue-70736-async-fn-no-body-def-collector.rs:15:26 | LL |     async fn associated(); |                          - type in trait ... LL |     async fn associated(); |                          ^ |                          | |                          the `Output` of this `async fn`'s found opaque type |                          expected `()`, found opaque type | = note: expected fn pointer `fn()` found fn pointer `fn() -> impl std::future::Future` error: aborting due to 6 previous errors Some errors have detailed explanations: E0053, E0706. For more information about an error, try `rustc --explain E0053`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-09 to nightly-2020-04-03 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
Maybe due to cc
Fixed by
Change:
//! Comparison traits for `[T]`. use crate::cmp::{self, Ordering}; <ins> use crate::ffi; </ins> use crate::mem; use super::from_raw_parts;

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
Failed(None) => { let segment_name = name.as_str(); let module_name = module_to_string(search_module); <del> let mut span = span; </del> let msg = if "???" == &module_name { <del> span.hi = span.lo + Pos::from_usize(segment_name.len()); </del> match search_parent_externals(name, &self.current_module) { Some(module) => { let path_str = names_to_string(module_path);

Discussion:
an arbitrary import of the shape will give the following errors and spans: The span is always as long as the crate, but starts at the imported element This can also be used to create an unprintable span:
Change:
<ins> // run-pass #![feature(generic_associated_types)] #![allow(incomplete_features)] // This test unsures that with_opt_const_param returns the // def_id of the N param in the Bar::Assoc GAT. trait Bar { type Assoc<const N: usize>; } trait Foo: Bar { fn foo(&self) -> Self::Assoc<3>; } impl Bar for () { type Assoc<const N: usize> = [(); N]; } impl Foo for () { fn foo(&self) -> Self::Assoc<3> { [(); 3] } } fn main() { assert_eq!(().foo(), [(); 3]); } </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
glacier ""
cc
Guess I should claim this too since its likely a duplicate of that issue? claim

<!-- 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 --
This no longer needs since minconst_generics has been stabilized. cc
claim
Change:
<ins> //@ check-pass // // issue: rust-lang/rust#120600 #![allow(internal_features)] #![feature(never_type, rustc_attrs)] #![rustc_never_type_options(fallback = "never")] fn ice(a: !) { a == a; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: 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: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
<ins> error[E0277]: the trait bound `T: Trait` is not satisfied --> $DIR/underconstrained_generic.rs:19:21 | LL | type Converter<T> = impl ProofForConversion<T>; |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Trait` is not implemented for `T` | note: required because of the requirements on the impl of `ProofForConversion<T>` for `()` --> $DIR/underconstrained_generic.rs:13:16 | LL | impl<X: Trait> ProofForConversion<X> for () { |                ^^^^^^^^^^^^^^^^^^^^^     ^^ help: consider restricting type parameter `T` | LL | type Converter<T: Trait> = impl ProofForConversion<T>; |                 +++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
// Decrement the reference count of the Arc on drop unsafe fn drop_waker<W: Wake + Send + Sync + 'static>(waker: *const ()) { <del> unsafe { Arc::decr_strong_count(waker as *const W) }; </del> <ins> unsafe { Arc::decrement_strong_count(waker as *const W) }; </ins> } RawWaker::new(

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- [ ] Can we improve the docs phrasing on ? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial PR in Stabilization PR in
Hello Would it make sense to also include similar methods for Rc? And possibly similar ones to both Weaks? It would be in part for the sake of completeness, but I do some manipulation like this in the arc-swap crate and if this would become the „official“ way, it would be nice to be supported on all the related types.
I think that's a great idea, and we should file follow-up issues to implement those.
Change:
/// Returns an iterator over the remaining elements of the original iterator /// that are not going to be returned by this iterator. The returned /// iterator will yield at most `N-1` elements. <ins> /// /// # Example /// ``` /// # // Also serves as a regression test for https://github.com/rust-lang/rust/issues/123333 /// # #![feature(iter_array_chunks)] /// let x = [1,2,3,4,5].into_iter().array_chunks::<2>(); /// let mut rem = x.into_remainder().unwrap(); /// assert_eq!(rem.next(), Some(5)); /// assert_eq!(rem.next(), None); /// ``` </ins> #[unstable(feature = "iter_array_chunks", reason = "recently added", issue = "100450")] #[inline] <del> pub fn into_remainder(self) -> Option<array::IntoIter<I::Item, N>> { </del> <ins> pub fn into_remainder(mut self) -> Option<array::IntoIter<I::Item, N>> { if self.remainder.is_none() { while let Some(_) = self.next() {} } </ins> self.remainder } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: There should be a remainder as will not be yielded. Instead, this happened: If this is intended behavior, then it should probably be documented, as the current documentation of states that it: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim