jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit a1232c451fc27173f8718e05d174b2503ca0b607 </del> <ins> Subproject commit 3dfd4d93fa013e1c0578d3ceac5c8f4ebba4b6ec </ins>

Discussion:
Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:

<!-- 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. --I found this issue when I was compiling one of my large projects, and was able to track it down to the code below. Unfortunately, I haven't been able to reproduce the issue on any other machines other than this one (which is running Ubuntu 20.02.4 on Oracle Cloud, if that matters). The error only seems to happen in release mode in nightly. <!-- 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. --: </p</details
label +A-LLVM
I can reproduce this via .
Reduced:
Upstream issue:
Change:
use rustc_middle::ty::layout::{LayoutError, LayoutOf}; use rustc_middle::ty::print::with_no_trimmed_paths; use rustc_middle::ty::GenericArgKind; <ins> use rustc_middle::ty::ToPredicate; </ins> use rustc_middle::ty::TypeVisitableExt; use rustc_middle::ty::{self, Instance, Ty, TyCtxt, VariantDef}; use rustc_session::config::ExpectedValues;

Discussion:
I would expect the following code to compile successfully since we explicitly opt out of implementing : However, the code fails to compile with the following error message: label C-bug A-lint F-negativeimpls <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The compiler only checks if the type implements already to return early and not emit the lint diagnostic but it doesn't check if the type implements :
I think this makes the trick, you are right! the last think is to explore what is the code of the method The code of the method looks not so trivial :) If you did not find already I can play with your on it by mentoring you, I had some experience in "git archeology" :) label +E-mentor
claim
Change:
<del> Subproject commit 1edd231065c8eb75abf42bb375adda2120c9a6bf </del> <ins> Subproject commit 1bfb26d6cae6f535ac1034877635fc0cef87fe64 </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! And nominating for compiler team prioritization.
Here's the fix by oli:
It looks like the PR is merged. Should this issue be closed or are there further steps to complete until it's fully fixed?
The submodule should be updated to fix toolstate.
Thanks! I'm trying to understand the protocol around tool breakages, so I was trying to understand why the issue wasn't yet closed :)
I'll get into Miri and then submit a submodule update that will close this issue. :) I often wait a bit after Miri is fixed before doing the submodule update, to collect more things into the same update. It's okay when Miri is missing for a few days.
Change:
<del> error[E0277]: the trait bound `[static generator@$DIR/static-not-unpin.rs:11:25: 13:6 _]: std::marker::Unpin` is not satisfied </del> <ins> error[E0277]: `[static generator@$DIR/static-not-unpin.rs:11:25: 13:6 _]` cannot be unpinned </ins> --> $DIR/static-not-unpin.rs:14:18 | LL | fn assert_unpin<T: Unpin>(_: T) {

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
let ptr = if is_sized { llargs[0] } else { <ins> // FIXME(#36457) -- we should pass unsized values as two arguments </ins> let scratch = alloc_ty(bcx, tp_ty, "drop"); call_lifetime_start(bcx, scratch); Store(bcx, llargs[0], get_dataptr(bcx, scratch));

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
&self, exclusive_range_pattern, pattern.span, <del> "exclusive range pattern syntax is experimental" </del> <ins> "exclusive range pattern syntax is experimental", "use an inclusive range pattern, like N..=M" </ins> ); } _ => {}

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// The test mode, compile-fail, run-fail, ui pub mode: Mode, <ins> /// The test suite (essentially which directory is running, but without the /// directory prefix such as src/test) pub suite: String, </ins> /// The debugger to use in debuginfo mode. Unset otherwise. pub debugger: Option<Debugger>,

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.
Change:
<ins> // Checks that the following does not ICE because `decorate` is incorrectly skipped due to // `--force-warn`. //@ compile-flags: -Dunused_must_use -Awarnings --force-warn unused_must_use --crate-type=lib //@ check-pass #[must_use] fn f() {} pub fn g() { f(); //~^ WARN unused return value } </ins>

Discussion:
Input:
Bisects to Rust 1.55.0, and nightly-2021-07-20. In older stable and nightly releases, this compiles successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection points to rollup If I had to guess, I'd say that looks like the one. It's the only one in the rollup touching diagnostic code. Possibly my reasoning is off (pls correct me).
Something went wrong with your bisect, as is from 2022-02-02, whereas this ICE is present in nightly-2021-07-20. looks the most likely to me.
Either way, this is probably easier to debug from scratch instead of digging around commits. Previous issue with this ICE message should reveal information on how to fix these issues, which arise from eagerly formatting paths in lints instead of only when they're emitted.
Fix for a similar issue :
Change:
<ins> // build-pass #![feature(generators)] static A: [i32; 5] = [1, 2, 3, 4, 5]; fn main() { static || { let u = A[{yield; 1}]; }; static || { match A { i if { yield; true } => (), _ => (), } }; } </ins>

Discussion:
I have some code which asynchronously computes an integer, and selects an item from a static slice in the same expression. This used to work (it does on stable), but after a nightly update the compiler ICEs when computing generator layout. The bug stops reproducing if I change the static to a local variable, or extract the index into a separate variable. rustc 1.41.0-nightly ( 2019-11-23) binary: rustc commit-hash: commit-date: 2019-11-23 host: x86_64-unknown-linux-gnu release: 1.41.0-nightly LLVM version: 9.0
De-nominating from compiler team as we have a fix pending.
triage: P-high.
Change:
--> $DIR/issue-74072-lifetime-name-annotations.rs:9:5 | LL | pub async fn async_fn(x: &mut i32) -> &i32 { <del> |                                       - let's call the lifetime of this reference `'1` </del> <ins> |                          - let's call the lifetime of this reference `'1` </ins> LL |     let y = &*x; |             --- borrow of `*x` occurs here LL |     *x += 1;

Discussion:
Output (): The lifetime name should be given to the second reference in the tuple. modify labels: C-bug A-async-await A-diagnostics A-lifetimes T-compiler
On stable the output is different: Per bisect-rustc, the commit that changed the output is - almost definitely . is there something that can be done to improve this case? <details<summaryBisect output</summarysearched nightlies: from nightly-2020-06-01 to nightly-2020-07-15 regressed nightly: nightly-2020-07-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Here's the output with removed: It looks like we're missing the "let's call the lifetime of this reference" note in the case.
The current equivalent of that annotation is the note at the bottom: (see ) I actually ran into this while testing a potential fix for that issue - it would make the output Which still points at the wrong reference.
Are you still planning to work on this?
Change:
// If we are computing `type_of` the synthesized associated type for an RPITIT in the impl // side, use `collect_return_position_impl_trait_in_trait_tys` to infer the value of the // associated type in the impl. <del> if let Some(ImplTraitInTraitData::Impl { fn_def_id, .. }) = tcx.opt_rpitit_info(def_id.to_def_id()) { match tcx.collect_return_position_impl_trait_in_trait_tys(fn_def_id) { Ok(map) => { let assoc_item = tcx.associated_item(def_id); return map[&assoc_item.trait_item_def_id.unwrap()]; } Err(_) => { return ty::EarlyBinder::bind(Ty::new_error_with_message( tcx, DUMMY_SP, "Could not collect return position impl trait in trait tys", )); </del> <ins> match tcx.opt_rpitit_info(def_id.to_def_id()) { Some(ty::ImplTraitInTraitData::Impl { fn_def_id }) => { match tcx.collect_return_position_impl_trait_in_trait_tys(fn_def_id) { Ok(map) => { let assoc_item = tcx.associated_item(def_id); return map[&assoc_item.trait_item_def_id.unwrap()]; } Err(_) => { return ty::EarlyBinder::bind(Ty::new_error_with_message( tcx, DUMMY_SP, "Could not collect return position impl trait in trait tys", )); } </ins> } } <ins> // For an RPITIT in a trait, just return the corresponding opaque. Some(ty::ImplTraitInTraitData::Trait { opaque_def_id, .. }) => { return ty::EarlyBinder::bind(Ty::new_opaque( tcx, opaque_def_id, ty::GenericArgs::identity_for_item(tcx, opaque_def_id), )); } None => {} </ins> } let hir_id = tcx.local_def_id_to_hir_id(def_id);

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
<del> error[E0606]: casting `&mut [u8; 2]` as `*mut u8` is invalid --> $DIR/vector-cast-weirdness.rs:21:23 </del> <ins> error[E0606]: casting `&[u8; 2]` as `*mut u8` is invalid --> $DIR/vector-cast-weirdness.rs:19:23 </ins> | <del> LL |     let p1: *mut u8 = &mut x1.y as *mut _; |                       ^^^^^^^^^^^^^^^^^^^ </del> <ins> LL |     let p1: *mut u8 = &x1.y as *mut _; |                       ^^^^^^^^^^^^^^^ </ins> <del> error: aborting due to previous error </del> <ins> error[E0606]: casting `&[u8; 2]` as `*mut [u8; 2]` is invalid --> $DIR/vector-cast-weirdness.rs:22:28 | LL |     let t1: *mut [u8; 2] = &x1.y as *mut _; |                            ^^^^^^^^^^^^^^^ error[E0606]: casting `&[u8; 2]` as `*mut [u8; 2]` is invalid --> $DIR/vector-cast-weirdness.rs:25:28 | LL |     let t1: *mut [u8; 2] = &x1.y as *mut [u8; 2]; |                            ^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0606`.

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
<ins> #![feature(generic_const_exprs)] #![allow(incomplete_features)] impl EntriesBuffer { fn a(&self) -> impl Iterator { self.0.iter_mut() //~ ERROR: cannot borrow `*self.0` as mutable, as it is behind a `&` reference } } struct EntriesBuffer(Box<[[u8; HashesEntryLEN]; 5]>); //~^ ERROR: cannot find value `HashesEntryLEN` in this scope fn main() {} </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
Triage: Fixed on the latest nightly, labels: +E-needs-test
Change:
<ins> // Regression test for issue #64803 (initial attribute resolution can disappear later). // aux-build:test-macros.rs #[macro_use] extern crate test_macros; mod m { use test_macros::Empty; } use m::Empty; //~ ERROR derive macro `Empty` is private // To resolve `empty_helper` we need to resolve `Empty`. // During initial resolution `use m::Empty` introduces no entries, so we proceed to `macro_use`, // successfully resolve `Empty` from there, and then resolve `empty_helper` as its helper. // During validation `use m::Empty` introduces a `Res::Err` stub, so `Empty` resolves to it, // and `empty_helper` can no longer be resolved. #[empty_helper] //~ ERROR cannot find attribute `empty_helper` in this scope #[derive(Empty)] struct S; fn main() {} </ins>

Discussion:
Compiling this: Results in an ICE: Different error on nightly: Backtrace for stable:
triage: tagging as P-high for initial investigation as to severity. Doesn't seem like it warrants discussion at T-compiler meeting. Removing nomination tag.
I'll try to look at this during the weekend. This is not a regression, so the priority is probably not especially high.
Fixed in
Change:
if (index !== -1 || lev <= MAX_LEV_DISTANCE) { if (index !== -1 && paths.length < 2) { lev = 0; <ins> } else if (searchWords[j] === val) { // Small trick to fix when you're looking for a one letter type // and there are other short named types. lev = -1; </ins> } if (results[fullId] === undefined) { results[fullId] = {

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:
/// assert_eq!(res, Poll::Ready(Err(0))); /// ``` #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[inline] </ins> pub fn map_err<U, F>(self, f: F) -> Poll<Result<T, U>> where F: FnOnce(E) -> U,

Discussion:
I noticed that in one of my project, inlining [] manually reduces some binary size, then I noticed is not marked . Since both [] and [] are marked , I wonder whether this is an oversight. I failed to reproduce the binary size reduction effect with an example code, but maybe the reason behind inlining and also applies to ? How about [] and []? []: []: []: []: []:
That's surprising. Can you share your project?
Unfortunately, it is a private project, I cannot share it.
Ah okay. I find it suspicious that these functions aren't inlining already. Did you try building your project against a modified standard library with to those functions? Do you still get a code size improvement from manual inlining if you compile with and/or in your release profile? The functions in question ought to already be eligible for inlining, but by default the release profile has multiple codegen units per crate, which can result in surprising failures to inline things. How big are these functions once they are compiled in your crate? The third-party tool can help out here, can you share the output of (of course trimming that down a bit if there are type names in there you don't want to fully disclose) If for whatever reason these functions end up looking big to LLVM after other things are inlined into them, that may explain what's going on here, and your manual inlining has effectively changed in what order LLVM considers inlining things.
I have done some tests on my project, using to check for symbols: Using , does not get inlined; Using , gets inlined; Using and , add to standard library source code, gets inlined; All configurations above are using and . reports that each is about 68 to 96 bytes.
What about and to the standard library code, but without using ? If that configuration gets these functions inlined I think this is worth doing because it unlocks additional useful optimizations for users, but if the optimization is gated behind it's a bit less certain if this is a win. Do you or any other LLVM folks have insight into why would be impactful here? Are we relying on the hint part of its behavior?
It seems that changing standard library source code only works with . Do I need to compile a customized version of Rust in order to test it?
That's what I do. It's a very slow workflow.
Change:
let num_trait_substs = trait_to_impl_substs.len(); let num_impl_substs = tcx.generics_of(impl_m.container_id(tcx)).params.len(); let ty = tcx.fold_regions(ty, |region, _| { <del> let (ty::ReFree(_) | ty::ReEarlyBound(_)) = region.kind() else { return region; }; </del> <ins> match region.kind() { // Remap all free regions, which correspond to late-bound regions in the function. ty::ReFree(_) => {} // Remap early-bound regions as long as they don't come from the `impl` itself. ty::ReEarlyBound(ebr) if tcx.parent(ebr.def_id) != impl_m.container_id(tcx) => {} _ => return region, } </ins> let Some(ty::ReEarlyBound(e)) = map.get(&region.into()).map(|r| r.expect_region().kind()) else { tcx

Discussion:
gives Build using the Nightly version: 1.67.0-nightly (2022-10-31 ) label F-asyncfnin_traits C-bug requires-nightly
searched nightlies: from nightly-2022-10-22 to nightly-2022-11-01 regressed nightly: nightly-2022-10-29 searched commit range: regressed commit: ' likely
Another repro which I believe is the same bug: