jiebi/CodeConvo huggingface dataset:
Change:
<ins> // compile-flags: --edition=2018 // run-pass macro_rules! regex { //~^ WARN unused macro definition () => {}; } #[allow(dead_code)] use regex; //~^ WARN unused import fn main() {} </ins>

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
<ins> // edition:2021 fn main() {} struct Error; struct Okay; fn foo(t: Result<Okay, Error>) { t.and_then(|t| -> _ { bar(t) }); //~^ ERROR mismatched types } async fn bar(t: Okay) {} </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. --This was in a closed source codebase I don't have time to minimize right now. It happened when I called (or something like that, don't exactly remember) on a value with type . Don't remember what T or E were :( <!-- 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
might be related to one of these ^^
Ugh, this is due to adding this  call -- something is calling this with a type that has region variables that no longer exist, probably from an or ... I can possibly try to reproduce, but this will be difficult to do without an MVCE.
can you try or is this a different issue?
This is a different issue. is a trait solver issue having to do with higher ranked type equality and the . This has to do with a region variable escaping out of a . Specifically it's this one:
Actually wait this is a type variable that's escaping. Ugh, probably due to opaque types :?
oh I forgot I saved this code I will try to trim it down to something I can post publicly
if you can, it would be incredibly useful here.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
use rustc_middle::ty::adjustment::{Adjust, Adjustment, PointerCast}; use rustc_middle::ty::fold::{TypeFoldable, TypeFolder, TypeSuperFoldable}; use rustc_middle::ty::visit::{TypeSuperVisitable, TypeVisitable}; <ins> use rustc_middle::ty::TypeckResults; </ins> use rustc_middle::ty::{self, ClosureSizeProfileData, Ty, TyCtxt}; use rustc_span::symbol::sym; use rustc_span::Span;

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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<ins> fn main() {} trait Foo { fn fn_with_type_named_same_as_local_in_param(b: b); //~^ ERROR cannot find type `b` in this scope } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by
Change:
(active, c_unwind, "1.52.0", Some(74990), None), /// Allows using C-variadics. (active, c_variadic, "1.34.0", Some(44930), None), <ins> /// Allows the use of `#[cfg(overflow_checks)` to check if integer overflow behaviour. (active, cfg_overflow_checks, "CURRENT_RUSTC_VERSION", Some(111466), None), </ins> /// Allows the use of `#[cfg(sanitize = "option")]`; set when -Zsanitizer is used. (active, cfg_sanitize, "1.41.0", Some(39699), None), /// Allows `cfg(target_abi = "...")`.

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
<ins> fn main() { // should hint to create an inline `const` block // or to create a new `const` item let strings: [String; 5] = [String::new(); 5]; //~^ ERROR the trait bound `String: Copy` is not satisfied println!("{:?}", strings); } </ins>

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
/// A trait to express the ability to consume an object and acquire ownership of /// its raw file descriptor. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "into_raw_os", since = "1.4.0")] pub trait IntoRawFd { /// Consumes this object, returning the raw underlying file descriptor.

Discussion:
Steps to reproduce: It's possible that this was accidentally stabilized, then feature gated later.
This seems to be caused by . I was thinking might address this, but I tried that PR and it doesn't seem to work. Maybe can confirm. cc
Looks like another case of , is stable but the module it lives in is not: Just need to add and it should work.
I'll work on this.
Using your suggested fix, I have a simple PR to address this, if you'd like to review: . I've confirmed locally that a toolchain built with this patch fixes the regression.
Change:
<ins> #![feature(rustc_private)] #[cfg(unix)] extern crate libc; extern crate run_make_support; use run_make_support::{aux_build, tmp_dir}; use std::fs; #[cfg(unix)] use std::os::unix::fs::PermissionsExt; use std::path::Path; fn main() { #[cfg(unix)] unsafe { libc::umask(0o002); } aux_build().arg("foo.rs").run(); verify(&tmp_dir().join("libfoo.rlib")); } fn verify(path: &Path) { let perm = fs::metadata(path).unwrap().permissions(); assert!(!perm.readonly()); // Check that the file is readable for everyone #[cfg(unix)] assert_eq!(perm.mode(), 0o100664); } </ins>

Discussion:
Given this code: I get this output from rustc: The most recent archive no longer has the "read" permission bit set for group/world owners. This ended up breaking because our files are built in a container with a different user and aren't then readable outside of the container. There's no particular reason we do this and we can work around this, but I also suspected that the change in permissions here probably wasn't intentional. I think this is due to (cc specifically . I haven't dug too deeply but my guess is that temp files specifically turn off other permission bits
reverted back to the LLVM archive writer to fix another regression. Still I think this issuw should be kept open as a reminder to fix the new archive writer before it becomes the default again.
cc , which also needs to be fixed before relanding the archive writer change. BTW is there a tracking issue for that somewhere? I see the original PR linked to , but it hasn't been reopened.
I have kept all issues that need to be fixed before it can land again in my github notifications. There is currently no tracking issue, but feel free to open one. It did probably be a good idea to ensure no issue is forgotten about.
Change:
<ins> // Copyright 2018 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. // run-pass trait Foo<'a> { fn xyz(self); } impl<'a, T> Foo<'a> for T where 'static: 'a { fn xyz(self) {} } trait Bar { fn uvw(self); } impl<T> Bar for T where for<'a> T: Foo<'a> { fn uvw(self) { self.xyz(); } } fn foo<T>(t: T) where T: Bar { t.uvw(); } fn main() { foo(0); } </ins>

Discussion:
This is a regression between rustc 1.20.0 and 1.21.0. 20 correctly rejects this code with the following error.
Tagging P-high because this very much affects Serde.
Same issue using Serde traits: (One possible) output:
Even better, :
Perhaps we can bisect this regression? (e.g., with )
Bisected to correct behavior in nightly-2017-07-07 -- rustc 1.20.0-nightly ( 2017-07-06), incorrect behavior in nightly-2017-07-08 -- rustc 1.20.0-nightly ( 2017-07-07). That range is Looks like
visited for triage. Assigning to
thanks, very helpful!
I think the bug is here: In particular, I think the condition is not strong enough. doesn't consider region annotations, so we probably need to not use this logic if there are any regions. But I'm wondering if the whole concept is flawed. I'm a bit fearful of regions being introduced through associated type normalization.
I have a fix.
Of course, any approach that relies on any lifetimes in the affected trait-ref is fatally flawed - here's an example where the trait ref is the region-free .
I'm not really sure what your example is meant to illustrate. That said, running that on my branch gives an error: This seems like the error I would expect, more or less. We try to use the impl to prove that but we fail to do so (because of the side condition that it adds).
BTW, the check looks like it happened because I used there, and an explicit check when he changed in to note be made true by late-bound regions.
visited for triage. bug seems to be being dealt with, assuming that PR is eventually deemed as passing muster...
Yes, I think that the "no late-bound regions" check was basically a workaround for this same problem; I removed it in the PR since I think it has a "more correct" fix.
Change:
.., // Any following adjustments are allowed. ], ) => { <del> // A reborrow has no effect before a dereference. </del> <ins> // A reborrow has no effect before a dereference, so we can safely replace adjustments. *entry.get_mut() = adj; </ins> } <del> // FIXME: currently we never try to compose autoderefs // and ReifyFnPointer/UnsafeFnPointer, but we could. </del> _ => { <ins> // FIXME: currently we never try to compose autoderefs // and ReifyFnPointer/UnsafeFnPointer, but we could. </ins> self.dcx().span_delayed_bug( expr.span, format!(

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> warning: the feature `adt_const_params` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-97047-ice-2.rs:3:12 | LL | #![feature(adt_const_params, generic_const_exprs)] |            ^^^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #95174 <https://github.com/rust-lang/rust/issues/95174> for more information warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-97047-ice-2.rs:3:30 | LL | #![feature(adt_const_params, generic_const_exprs)] |                              ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information warning: 2 warnings emitted </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
A reduced version: Tested in using
The other ICE block is also standalone
for the first example: ` Regression in :thinking: EDIT: same for the second snippet.
This is caused by Seems as if this issue takes care of FIXME ^^. Not sure what the right solution is, we originally tried to skip reborrows because implicit autorefs/autoderefs lead to confusing error messages given that we don't support derefs and refs in abstract consts. Maybe the right solution is to just clarify that autorefs/autoderefs happen there. Thoughts
No longer ICEs since (perhaps due to ?)
Change:
use crate::deref_separator::deref_finder; use crate::MirPass; <del> use rustc_data_structures::fx::FxHashMap; </del> use rustc_index::bit_set::BitSet; <ins> use rustc_index::IndexVec; </ins> use rustc_middle::mir::patch::MirPatch; use rustc_middle::mir::*; use rustc_middle::ty::{self, TyCtxt};

Discussion:
This code creates MIR statements based on an iteration order: is defined as: Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect). We should probably sort by before creating the statements.
Perhaps it should just use instead?
Revisiting this issue to evaluate the priority. unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on . Unsure if it helps and - if yes - how much does that pull request covers to fix this issue. opinions? thanks :)
Change:
endif endif <del> CFG_COMPILE_C_$(1) = '$$(CC_$(1))'  </del> <ins> CFG_COMPILE_C_$(1) = '$$(call FIND_COMPILER,$$(CC_$(1)))'  </ins> $$(CFLAGS)  $$(CFG_GCCISH_CFLAGS)  $$(CFG_GCCISH_CFLAGS_$(1)) 

Discussion:
I'm building Rust with , it fails at the miniz step:
This is due to , specifically . The problem is that --enable-ccache exports and it's ambiguous whether that's a file name with a space in it or two arguments.
Change:
// Try to lookup name in more relaxed fashion for better error reporting. let ident = path.last().unwrap().ident; <del> let candidates = self </del> <ins> let mut candidates = self </ins> .r .lookup_import_candidates(ident, ns, &self.parent_scope, is_expected) .into_iter()

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should look like: In cases where intrinsics have been stabilised in | it would be useful to suggest these to users first. Especially as using intrinsics generates another error that tells you to prefer stabilized functions in . This would hopefully make handling this error easier for new rust users coming from languages like C/C++ and looking for the equivalent of <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --The output is the same on stable, beta and nightly
I'd be satisfied if we filtered out intrinsics altogether except for when the feature was enabled.
I also get quite annoyed when stable rustc recommends I use unstable features (maybe that should be fixed in an RFC)
Checking the DefId of each suggested path to see if they are annotated with should be doable.
This seems to be harder than I initially thought... so since we emit this "consider importing" suggestion in , we do not have access to it seems. And I have no idea how to extract the attributes from each without ... :thinking:
We might want to consider adding yet another dumping ground field in the itself or in ... But at that point it seems like too much mem consumption for little gain. The other option is to delay the emitting of these errors until later, but that also seems... like a lot of additional complexity :-/
For now, I guess it wouldn't hurt just to filter suggesting paths that are literally (and ) instead of going thru all of the work of adding more info to the . I can put up a PR that does that later.