jiebi/CodeConvo huggingface dataset:
Change:
item.id, &[], false, <ins> false, </ins> // The whole `use` item item, vis,

Discussion:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!
Change:
<ins> error[E0261]: use of undeclared lifetime name `'tcx` --> $DIR/issue-107988.rs:7:52 | LL | impl<T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |      -                                             ^^^^ undeclared lifetime |      | |      help: consider introducing lifetime `'tcx` here: `'tcx,` error[E0261]: use of undeclared lifetime name `'tcx` --> $DIR/issue-107988.rs:7:30 | LL | impl<T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |                              ^^^^ undeclared lifetime | = note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html help: consider making the bound lifetime-generic with a new `'tcx` lifetime | LL | impl<T: ?Sized + for<'tcx> TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |                  +++++++++ help: consider introducing lifetime `'tcx` here | LL | impl<'tcx, T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |      +++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </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 --
claim
are you working on this?
yes
Change:
<ins> error[E0282]: type annotations needed --> $DIR/issue-64662.rs:2:9 | LL |     A = foo(), |         ^^^ cannot infer type for `T` error[E0282]: type annotations needed --> $DIR/issue-64662.rs:3:9 | LL |     B = foo(), |         ^^^ cannot infer type for `T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
Following code ICEs on today's nightly ( 2019-09-20): What's peculiar is that no ICE is shown when the enum contains only one item:
Backtrace:
This is because the discriminant assignment code tries to increment the discriminant of the previous variant, which was an error, and thus fails in a different way to the first. However, the code looks like it handles that case, so I'm not yet sure what's going wrong here. Edit: I think there's some state changing inside — the discriminant assignment code seems to be working as expected. is being called with essentially identical arguments, but something about the first error is causing the second one to behave differently.
It's not a regression. Stable shows I don't see how we could be keeping state. Maybe it's happening because there's no "cannot infer type for " error on anything but the first item? So is never evaluated, thus not causing an ICE.
Hmm, perhaps. In that case, it's simplest just to instead.
This , though it does ICE on beta. We now get type inference errors on both variants.
Reopening, as we should have a test.
Change:
use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{error_code, DelayDm, Diagnostic}; use rustc_hir::def_id::{DefId, LocalDefId}; <del> use rustc_middle::ty::{self, ImplSubject, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, ImplSubject, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_middle::ty::{InternalSubsts, SubstsRef}; use rustc_session::lint::builtin::COHERENCE_LEAK_CHECK; use rustc_session::lint::builtin::ORDER_DEPENDENT_TRAIT_OBJECTS;

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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
return; } <del> if let Some(stab) = tcx.lookup_stability(did) { if stab.is_unstable() && stab.feature == sym::rustc_private { </del> <ins> if !tcx.features().rustc_private && !cx.render_options.force_unstable_if_unmarked { if let Some(stab) = tcx.lookup_stability(did) && stab.is_unstable() && stab.feature == sym::rustc_private { </ins> return; } }

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
Some(blk_id), ); if !fcx.tcx.features().unsized_locals { <del> unsized_return = self.is_return_ty_unsized(fcx, blk_id); </del> <ins> unsized_return = self.is_return_ty_definitely_unsized(fcx); </ins> } if let Some(expression) = expression && let hir::ExprKind::Loop(loop_blk, ..) = expression.kind {

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
bisected to cc
This can be made to ICE on stable as well:
duplicate of

<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `
Change:
DefId { krate: cnum, index: def_index } } <del> fn expn_hash_to_expn_id(&self, cnum: CrateNum, index_guess: u32, hash: ExpnHash) -> ExpnId { self.get_crate_data(cnum).expn_hash_to_expn_id(index_guess, hash) </del> <ins> fn expn_hash_to_expn_id( &self, sess: &Session, cnum: CrateNum, index_guess: u32, hash: ExpnHash, ) -> ExpnId { self.get_crate_data(cnum).expn_hash_to_expn_id(sess, index_guess, hash) </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. --Assuming that you copied to . <!-- 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
I reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
if let Some(lockfile) = test.lock { fs::write(&dir.join("Cargo.lock"), lockfile).unwrap(); } <del> if !run_cargo_test(cargo, &dir, test.packages, test.features, test.manifest_path) { </del> <ins> if !run_cargo_test(cargo, &dir, test.packages, test.features, test.manifest_path, test.filters) { </ins> panic!("tests failed for {}", test.repo); } }

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
<del> // Caveats - gdb prints any 8-bit value (meaning rust I8 and u8 values) // as its numerical value along with its associated ASCII char, there // doesn't seem to be any way around this. Also, gdb doesn't know // about UTF-32 character encoding and will print a rust char as only // its numerical value. </del> <ins> // Caveat - gdb doesn't know about UTF-32 character encoding and will print a // rust char as only its numerical value. </ins> // min-lldb-version: 310 <del> // ignore-gdb // Test temporarily ignored due to debuginfo tests being disabled, see PR 47155 </del> <ins> // min-gdb-version: 8.0 </ins> // compile-flags:-g // gdb-command:run

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
/// /// For example given: /// <ins> /// ```no_run </ins> /// trait X<S> { fn f<T>(); } /// impl<U> X<U> for U { fn f<V>() {} } <ins> /// ``` </ins> /// /// * If `self` is `[Self, S, T]`: the identity substs of `f` in the trait. /// * If `source_ancestor` is the def_id of the trait.

Discussion:
Documentation generated for and any code after is all strikethrough because of the . Generated doc: Associated src code: cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: T-rustdoc C-bug
This is normal and expected markdown behavior. trait X<S{ fn f<T(); } impl<UX<Ufor U { fn f<V() {} } </SIt needs to be placed in a code block to avoid that (or use escapes).
It affecting that specific piece of item doc - expected behavior It affecting the rest of page - duplicate of
Duplicate of
I don't think this should be closed until the docs for are changed not to have strikethroughs everywhere.
Sure, adjusted the title to better reflect the scope of the issue.
claim
modify labels: -T-rustdoc +T-doc
Change:
} else if let Some((hir_id, _)) = visitor.attr_main_fn { Some((tcx.hir().local_def_id(hir_id).to_def_id(), EntryFnType::Main)) } else if let Some(def_id) = tcx.main_def.and_then(|main_def| main_def.opt_fn_def_id()) { <ins> // non-local main imports are handled below if def_id.is_local() { let hir_id = tcx.hir().local_def_id_to_hir_id(def_id.expect_local()); if matches!(tcx.hir().find(hir_id), Some(Node::ForeignItem(_))) { tcx.sess .struct_span_err( tcx.hir().span(hir_id), "the `main` function cannot be declared in an `extern` block", ) .emit(); return None; } } </ins> if tcx.main_def.unwrap().is_import && !tcx.features().imported_main { let span = tcx.main_def.unwrap().span; feature_err(

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 minimal, but possibly helpful, from <!-- 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 --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar
Change:
<ins> // Copyright 2017 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. // #45662 #![feature(repr_align)] #![feature(attr_literals)] #[repr(align(16))] pub struct A { y: i64, } pub extern "C" fn foo(x: A) {} fn main() {} </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.
Change:
<ins> // check-pass use std::future::Future; pub trait Service { type Response; type Future: Future<Output = Self::Response>; } pub trait A1: Service<Response = i32> {} pub trait A2: Service<Future = Box<dyn Future<Output = i32>>> + A1 { fn foo(&self) {} } pub trait B1: Service<Future = Box<dyn Future<Output = i32>>> {} pub trait B2: Service<Response = i32> + B1 { fn foo(&self) {} } fn main() { let x: &dyn A2 = todo!(); let x: &dyn B2 = todo!(); } </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
searched toolchains through Regression in hmm
what's your system? do you have debug builds on? I can't seem to repro this on master. edit: oops, first question i guess is
no this is not with debug build on, its just the normal master toolchain installed via on x86
Literally can't repro this locally. I'm pretty sure that I know the reason why (the function, which is called from isn't actually returning a sorted list of elaborated predicates). This must be because we're calculating def path hash or something differently between the CI master build and a local build of master.
so you can't even repro with the official master artifacts? :| or just not with a local build?
Sorry, I can repro with the master artifacts. But not with a local build of master, which makes testing the change that I want to make to fix this issue difficult.
Actually, repro on ~stable~ whoops I mean nightly: This should be a UI test that is resilient to def path hashing changes.